How Could We Fail? We Always Delivered 90% of Our Sprint Backlog!!
Kinshuk Kale
CEO | CEO Advisor | Speaker | Author | Product Management Evangelist | Proponent of Continuous Discovery
I have seen many, many teams who prided themselves in meeting the sprint commitment in terms of % story points delivered. Numbers varied between 80% and 100%, but it was always about completing the stories taken up in the sprint. Interestingly, none of these teams had a cohesive sprint goal. Eventually, in spite of their hard work, the teams ended up losing the confidence of their customers and stakeholders. This made a lot of people confused and unhappy.
This happens because teams are so focused on completing the stories that they lose the sight of WHY they had to deliver those stories. Everyone is busy, but nothing was getting done in terms of business outcomes. In the sprint reviews, these teams end up talking about % complete backlog instead of talking about business outcomes achieved. Keeping the project manager happy becomes the goal instead of getting real feedback from the customers or end users.
If this type of 'story completion obsession' is encouraged and promoted by the leadership, eventually the focus of teams becomes 'delivering software fast' rather than 'delivering value fast'. Teams optimize for speed instead of learning, which leads to creation of silos and islands of expertise in the team. Eventually the whole thing becomes unsustainable and the product either stagnates or fails.
Whether a team has a cohesive Scrum Goal for each sprint or not, and whether they mostly meet it or not is a good predictor for the long term sustainability of the team.
Jack of all IT trades, master of quite a few
5 年Given that it is (should be) the teams own estimates and agreed upon velocity that form the base for the sprint scope commitment, completion percentage deviation is a statistical aberration that should be rather uninteresting for anyone but the team. But I do believe that a 'sprint story' as in posing the question 'what will we be able to say about the system after this sprint that we couldn't before' helps focusing on delivering actual value in every sprint. Also, probably, this would help the devs to understand their own contribution better, which tends to boost morale.?
Agile Coach at CirrusLabs
5 年Always delivering 90% means that we are always leaving 10% not done. I would wonder why we are missing a constant 10%? Is it because we have a 60% bug fix for the code delivered when we expect only 20%., Is it because we are being pulled off what we are supposed to be working on and our time (10%) is being spent in meetings and not accounted for. Are we not contagiously improving so we are stagnant? Tracking where the team members spend time is important to know so we can understand how much time is available for the developers to code/test. Full time ScrumMaster vs part time can see where the team is spending time. Back long ago in the dark ages of the 80s, I had a friend who started drinking beer on Friday at noon, then spent Monday fixing the code he wrote on Friday. There are lots of places to look, but the author is correct, knowing what the REAL GOAL is would also be wise. Vision statements focus our thoughts on the goal of satisfying the customer. Making our sprint goal should be secondary.
Results Improvement catalyst for you, your org, teams and leaders; conflict resolution; ACE Certified Exec Coach; Speaker; Fearless Org Scan Practitioner; ACC; KMP; ICAgile Instructor; SAFe SPC; OpenSpace Facilitator
5 年I have to wonder if their product owner had a sprint goal vision. Perhaps part of root cause is a not quite working product function?