Saturday, April 05, 2014

Why Story Points are Cool

Sure.  Dilbert Comic.



So to carry on the conversation where some people are saying that estimates, in general, are a waste of time, I'd like to cover some situations where having Story Points are particularly useful.

Do we agree on the requirements?
You really shouldn't need an excuse to drag product/business end users, qa, and developers to have one last sanity check on some requirements.  Getting everyone to agree, at the very least, what the requirements ARE and taking the next step to cover some technical detail as to what the effort would be.  You definitely don't want "the expert" to do the estimation as this is a method of risk mitigation of "expert getting hit by bus."

Do I have enough ready-to-work Stories in the Backlog?
As a product owner, you need to know whether you have enough stories pokered and agreed upon by the team for the next sprint.  This is dependent on knowing your team's average velocity, whether people are going to work vacation days, etc.

Also, depending on your team's process, a Product Owner can ensure that the backlog consistently has a decent amount of low point stories that the team can incorporate into their own sprint.  This is for teams that have the rule that a developer can bring in a story after the sprint start only if they think they can complete the added story within the same sprint.

When are we done with Planning?
Pretty much exactly the same thing as the previous point.  More importantly, when can you end the planning meeting?



Where Story Points don't help:
One scenario where Story Points may just be superfluous, and that is when a team typically breaks a story down to the point where they are all essentially equivalent levels of effort.  This exercise is particularly useful for teams with extremely short sprint times.  This all depends on what your team wants to accomplish and how they want to accomplish things.  However, if just about all stories are broken down to 3 point stories, you are still running through the exercise of Pokering, but rather than asking the question "what's the level of effort for this story," you're asking "is this story a 3 or not?"

... but don't get too focused on those Points
It's really easy to latch onto some quantitative value and to start drawing conclusions.  People are going as far as to asking "why are we FAILING our COMMITMENT?!"  In the end, Story Points are just a tool to help us answer the following, but not used as the ONLY metric to answer:

  • Are we meeting customer expectations?
  • Is there any action we can take to improve?
This is really hard to drive home for a lot of people and you're likely going to have a couple "electrolyte" conversations but it is truly worth it.

... but what about our commitment?

Either way, I hope this will provide some ideas for Product Owners in particular in using Story Points to help manage not just their own day-to-day work, but also drive home that it's just a tool to aid in efficiency and identify potential areas for improvement.  We should never become slaves to our estimates.

No comments: