One of the Agile Scrum teams that I was coaching Agile Artisans was doing pretty well and I felt had matured enough to be on their own. I was paying less attention to them. They had achieved a good velocity in the recent completed Sprint 14. it was quite high compared to their past velocity. The manager of team sent them a congratulatory message and the team was in high spirits.
I was a bit surprised by the results and looked into the details and found that some large stories that were long pending and blocked in the past due to external dependencies were completed in the sprint. I was pondering on how to take it to the them, when Anjan the Scrum Master came over. He shared that he was almost certain that the team is estimating higher story points for the stories. He knew this was due to the recent increase in velocity and resulting appreciation. (This was a classic case of incorrect messaging be managers/leaders.)
He was aware why the recent velocity was high, but was wary to communicate to the team as they were all on a high, the news had spread and they were the talk of the town. He wanted to know how he could get them back on track without have any adverse reaction. What would be your inputs/approach to this issue?
Suggested Solution:
I asked Anjan, what would you like team to do?
Anjan responded that I would like them to deliver more stories more value to the customers.
How will we know that is happening?
Anjan: Well we could look at how many stories they are completing, paused and added, well currently we just look at the velocity only in terms of story points.
I said that is something we could try, what do you think of looking at story count along with story points?
Anjan: I think it could work, will give it a try.
He was getting familiar with the tool used to track progress and had learned about cycle time, he could quickly connect cycle time with this and decided to measure that too. The key was that this should be visible to the team – it was made so by sharing sprint metrics during retrospective and reviewing the progress a few times in the course of the sprint. The team starting looking at story count/throughput over and above the velocity and it bought in the correct focus in the team.
2 Responses
While the solution is simple, its implementation will be tough since the business would not easily sponsor them. While it is a good idea to write all technical debt stories, generally, there will not be any Product Owner who likes to own and accept since the PO comes with business mindset. These kind of work is pushed by external team (not the scrum team). Generally, these is a lack of ownership of these stories and pushed by external teams. I am purposefully, I am not the solution this gap in this comment. Want to hear from others.
I agree Guru. The reason why i mentioned this as a Dilemma for the Engineering manager is do we handle only the low hanging fruits and run with it, or would you work for a harder and more difficult transformation of creation of a working pipeline.
I know one manager I have interacted made the call and felt the next 6 months extremely hard to convince and influence different stakeholders. This is easier to accept while you are doing a transformation.