Focus on the work, not story points — Part II (lesson learnt)
11 Dec 2017 Edit: read some awesome articles from Ron Jeffries
So if you want to keep story points in your Scrum, if you want to do Scrum without actually producing software, if you want to produce software using silos instead of teamwork, well, you have a right to do that. I wish you wouldn’t call it “Agile”, but you have a right do do that as well.
Velocity is so easy to misuse that one cannot recommend it. We did say “working software as a measure of progress”, and that’s still the best I’ve got. I no longer recommend velocity, which means that I also no longer recommend story estimation in points or other measures.
Better estimation seems possibly helpful, but its effect is to improve along the Estimate-Commitment axis, which is harmful to the Collaboration axis.
After part I was published, I managed to convince Product Owner, Project Manager (yep, we do have this role within our Scrum Team due to the complexity of the project we are working on) and Scrum Master to give that idea a try. I experimented this idea in our current sprint, and found it is not work as expected.
How it worked
We have a prioritized backlog. Roughly, in every sprint planning meeting,
- Team’s capacity is defined by X story points (based on how we have been tracking in last Y sprints)
- We estimate stories in their priority order
- Once the total of story points is around X, we stop and think those stories are the scope of the sprint
How we are experimenting
In this week’s sprint planning meeting,
- We have tried WIP limit where team’s capacity is defined by 4 stories per developer
- We looked at 2 must-have stories, and then a few should-have stories
- Once the total of stories reach the WIP limits (say 16 stories for 4 developers), we stop and think those stories are the scope of the sprint
Fundamentally, both approaches are same. The team focuses on how to get each sprint filled with fixed X points of stories or X cards. However, they will all end up with same situation where some stories won’t be complete and will be carried over to following sprint which causes frustration and lost of trust, etc. This is because the focus is wrong. In my opinion, what team should focus on is to see if and how highest priorities can be delivered by the end of sprint. Team should not be committed to X points of stories or X cards, but the delivery of highest priorities or business values (then ownership will naturally comes). This also avoids questions like “Just give me the points then let’s move on” in which case the points are pointless.
What I learnt?
- Instead of having a fixed X stories per developer or fixed points of stories per sprint, team focuses on delivering high value features, and needs to decide if and how highest priorities can be delivered by the end of sprint. It means team decides how many total stories (WIP stories, team capacity) are in each sprint. It also implies that WIP limits vary in different sprints.
- Do not over commit what we can do since team can always pull next priorities (during daily standup, team may notice if there are less stories in TODO, then it means pull needs to be triggered soon)
- If a high priority is too big to be delivered in one sprint, let’s break it down into phases so that each sprint can focus on and deliver different phases
- Do not categories backlog as must-have, should-have; the backlog items should be simply ordered by their priorities (must-haves are always first, and should-haves always come after, etc.)