Friday, June 07, 2019

Sprint planning and estimation are not the same thing

I run 10-minute sprint simulations in my classes and notice something consistent. When left to their own devices, teams will plan out the sprint but not estimate much.

For a while, that bothered me.  Weren't they listening in the class?  Then it occurred to me: when I work on my own projects, I plan out what I hope to accomplish, but I don't estimate much either.

OK, so I don't have a deadline or contract with my own work and neither do my course attendees.  Maybe that's the difference.

But then again, we're talking about sprints, which are time-boxed. We know when they end.  We also know a sprint's input, the sprint goal, and the output, which are the new features added to an improved game. We typically forecast the future progress of the game by measuring the average output per sprint and multiplying it by the number of sprints remaining.

Planning a sprint is usually a discussion of what a feature needs to do and the work needed to implement it. This is often followed by creating tasks such as "model the character"or "rig the model", etc. This is a useful discussion which reveals questions with the goal and generates discussion.

In addition, teams will put often estimates on those tasks, usually in time. There are a number of typical reasons for this:

  1. It can further discussion by revealing misunderstandings about the effort and complexity of a task and help refine the goal. Many times I've heard large numbers being thrown out which revealed a misunderstanding of the existing tools or tech or a shortage of a certain discipline's capacity.
  2. Estimates are used to create a forecast of the work the team will commit to achieving with the Product Owner.
  3. Estimates are used to track team progress throughout the sprint.
I see the value in #1, but often see #2 and #3 being misused. This reflects back to the Scrum values of commitment and respect:
  • Commitment: This doesn't mean the team commits to a fixed amount of work. Work is often unpredictable and iterative. When we aim for a fixed amount of work every time, we often have to compromise quality to get there. Commitment is more about doing our best work to achieve a goal, but also committing to doing it with quality.
  • Respect: You can't respect those you don't trust.  Too many times I see teams being tracked using their own estimates and being punished if those estimates are incorrect. All this leads to is padding, disengagement, debt and compromised quality.
Try this
If you truly want to measure progress, measure just the output of the team. Let the team decide how to plan and at what level to estimate. It can take some courage, like when I finally had to hand over the car keys to my son for the first time. But as with him, I had to make sure he was first ready. That's my job as a dad. Similarly the job of coaches and leaders is prepare their teams for higher levels of maturity and self-organization.

Sure, some teams might not work well together and their output will show it. It's far better to coach teams on creating better value than creating better estimates.

No comments: