Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons:
- “Beating” the last sprint goal
- Assisting the PO in a forecast of when things might be done.
Let’s examine these ideas.
Clarify Story Points
Why even bother with story points? (If you haven’t read the original ideas, as in Essential XP: Card, Conversation, Confirmation, please do.)
We write a story on a card, possibly only as a phrase. The conversation fleshes out the story and helps us see the complexity. We can then create acceptance criteria and tests, so we get confirmation we do understand. We now understand the intent and we have acceptance criteria.
Back when teams only worked on one project at a time, it made some sense to estimate in story points. Why story points?
- Points helped the team members discuss the story complexities, how much work all the tests would be, those story issues.
- Points helped team members differentiate the smaller, medium, and larger stories.
- We could use points as a way to estimate how much we could do in an iteration, assuming iterations work for the team.
Especially now that more teams tend to work on a variety of work—not just one product’s stories—I find story points less useful. I find it difficult to compare story points across feature sets or products. I’ve never seen them normalize unless you have one-day or smaller stories.
Notice that points are output. Finished stories are outcomes.
Outcomes Over Outputs
Output measures are useful in the moment. However, outputs don’t always offer value to the customer. (Example: I use my daily steps as an output measure. My daily steps are useful but not all I need to create health.)
This chart shows a burnup of two measures: The cumulative story points (6) and the number of stories done (2).
The points are interesting, and not sufficient. Why can this team only finish two stories, and only at the end of an iteration? That’s very interesting.
Stories completed are an outcome. They offer value to someone.
If you want to increase the number of story points in an iteration, I hope you also increase the number of stories in the iteration. Otherwise, you’re playing an agile schedule game: Double Your Velocity, Everyone Start Your Own Story, or We Can Do More.
Sure, you can do more points. Points are outputs. Are you delivering more finished work? Those finished stories are outcomes.
Can You Use Story Points to Forecast?
Please read Estimation and Forecasting to see my favorite story point scale: 1, too large, no clue. (Pawel Brodzinski developed that scale.) In that article, Larry Maccherone says that counting stories works just as well as story points. My experience is that counting works much better. So will cycle time measures.
I would also ask what kind of an estimate do you need? That’s a whole different discussion.
I wrote about how to estimate with cycle time and counting stories in Create Your Successful Agile Project. I wrote about estimation in general in Predicting the Unpredictable.
Maybe you don’t believe my assertion that story points do not enhance your forecasting ability. In that case, consider an experiment. For the next two iterations (so you have enough data), track these items:
- The number of story points per story you commit to in an iteration.
- The number of stories those points represent.
- The number of stories you complete in an iteration. (I recommend tracking this data on a burnup as above.)
- How long (cycle time) each story took.
- How much WIP (Work in Progress) do you have at the end of an iteration? That’s unfinished work. You can’t claim any points were done. You get no partial credit.
You now have enough data to see your answers to these questions:
- Does counting stories work as well as story-pointing for your team?
- When you paid attention to cycle time, did your behavior change?
- Did your WIP go up or down as you gathered this data?
I don’t know what you will discover. That’s why it’s an experiment.
What About Feeling Good About Beating Previous Data?
I haven’t forgotten the feeling-good part. Because points are an output, I recommend teams move to track their WIP and cycle time instead of velocity. (See When Teams Don’t Finish Work in a Sprint: 3 Tips to Seeing and Finishing Work for a cumulative flow chart.)
When I coach teams (at all levels), I ask them to focus on the outcomes they want. And, on the cycle time it takes to achieve those outcomes. That’s why I ask managers about their decision times. The decision matters—managers’ decisions enable other people to achieve their outcomes.
The more your team can decrease its cycle time, the better they can feel about themselves. They move faster to create outcomes.
Which Measures Matter?
Velocity, in terms of story points, is an output measure. Sure, it might be a good indication that the team has trouble or the team managed to collaborate or that the team’s efforts in automating the build or tests paid off.
Velocity is not an outcome.
What outcomes matter to your team? Find a way to measure those and see if you can achieve those outcomes faster. That’s how you beat a team’s goal.
(Shaun, thanks for a great question!)
Addendum post-lunch: I forgot to say this: story points are a surrogate for duration, not date. If you want dates, use cycle time. If you want to predict durations, I still see cycle time as a more valuable tool
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Thinking About “Beating” a Team’s Goal Opinions expressed by Java Code Geeks contributors are their own. |
