You can commit to iteration planning by doing commitment-driven Sprint planning or by doing Velocity-driven Sprint planning. Okay, great. What if I do not know the Velocity? What if I do, but still don’t know how to plan the Sprint because I cannot determine how important each Story is? And then, what if those stories disaggregate and we have more stories… multiplying like rabbits and everyone is saying that each one is “critical” or “oh we *definitely* need that one…?
I had what I thought was a pretty slick method, but the truth is I was always refining it. It had to do with Value, of course. It looked something like this:
- Business Value (1-5) or 100 if it is something we cannot go live without
- User Value (1-5) or 100 if it is something we cannot go live without
- Technical Difficulty (1-5) or 100 if it is something we think is akin to magik in the deep woods of The Black Forest
You add these (after applying a multiplier if for instance, User Value is 20 percent more important than anything else) so you get something like this:
UV = ((2.3)(1.2)) times BV (3.2) times TD (5) equals 44.16
This would usually (or could) be the end result of a Faceted Feature Analysis (FFA), where the Product Owner does not name all the values themselves all the time. I would encourage them to ask stakeholders for their values and then do the classic Planning Poker thing. “Jane, you say having a stock ticker is a 5 and Bob, you say it is a 1. The rest of you are 2 or 3. Jane, Bob, can you explain why your values make sense to you?” Then, final voting. Depending on the circumstance you may want to document (if you have to) that Jane and Bob still did not agree or maybe they did not realize and will agree to a 2.5 or a 3 or whatever it works out to. The goal is to get that final number. Also, if that number is over 100 you really need to examine it. What being over 100 is saying is that this is a major deal, and might require more exploration.
Of course you also get the Technical Risk this way. I like that because high value, high risk stories are identified early and you can play the Fail Fast game. Lots of people want to implement the low risk and high value stories first, but since something like a third of features built are ever used, it makes good sense to figure out as soon as possible if something cannot be done, if part of that something is good enough for now, or if holding onto it like Linus and his blanket would only mean you cannot swim when you are in the water of the project.
BigVisible presents another way, which is simpler, and I like for other reasons:
They talk about the Kano Question Form and Kano Analysis. I will do that later, since is would be a tangent on the theme here.
They use what I will call the “Nines Approach” (or at least they proffered it along with the disclaimer that it is not THE ONLY way).
Looks like this:
Which one of these is right? Both. Neither. What is right is the third way to assign Priority: be Agile. The second method makes it a little harder to Fail Fast without some conversation, but that is actually good: you *want* the Team to talk.
In some situations the first approach or the second approach may speak closer to what your team understands and likes. In some, it will be a balance of the two plus or minus a Tradeoff Matrix. Some will want to see a weighted Feature Prioritization. Some will not care as long as the Product Owner or *someone* tells them what the goal of the Sprint is.
Thanks to Big Visible, Giora, and my wife for helping me with some crazier ideas that will be in a future post.
Best,