TynerBlain: Plan Your Next Sprint By Bang For The Buck: Part 2
Giants. And Their Shoulders.
I had a great conversation over the weekend with Luke Hohmann, founder and CEO of Enthiosys, and realized my mistake. Consider the titles of three (excellent) articles Luke wrote earlier this summer:
Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
Developing Attributes for Backlog Prioritization (Part 2 of 3)
Prioritizing for Profit (Part 3 of 3)
Not to mention giving a presentation at Agile’08.
You’d think I would have noticed, and been more careful in my use of language. Sorry about that.
Luke, in his first article, provides several arguments against econometric assessment of ROI, and I agree with all of his points. In his second article, Luke goes into details about defining attributes for reflecting the goals of internal stakeholders, external stakeholders (buyers and users), and the system. I promised to do the same in this article, but frankly, why reinvent the wheel? Our differences from Luke’s article would at best be nuanced, so the best use of your time (and mine) is to just go read his second article.
Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.
Developing Attributes for Backlog Prioritization (Part 2 of 3)
Including Costs in Sprint Planning
There are two dimensions by which to keep costs in mind when planning a sprint. The first is in determining how much work to schedule for any given sprint. When you use timeboxing to plan a sprint, you’re saying “we have the capacity to do X work per sprint” and “we should only schedule X work per sprint.” Your plans are based on estimates, so you need to have a feedback mechanism to make sure you’re doing a better job in planning each sprint than you did with the previous sprint. Burndown graphs are a great way to do this. The burndown provides feedback within the sprint too, not just at the end.
Mike Cohn, of Mountain Goat Software, gave a great presentation on how to estimate costs for an agile project. Without giving it away, he proposed (starting on slide 14) using planing poker to get quick estimates of user stories [more details] at the product backlog level. Then, more detailed estimates are created for the tasks within the sprint. If your team uses use cases, you can choose to use use case points as a low-overhead estimation method (but not nearly as low as planning poker) to determine the initial estimates of costs.
27 Oct 2008 | Source: Tyner Blain
