When Kent Beck first articulated the principles of agile programming, he spearheaded the greatest change in software methodology in the last twenty years, and therefore perhaps of all time in such a young art. As I cannot hope to improve upon his exposition of the synergetic principles of Extreme Programming, I would like to explain how agile programming relates to Portfolio Management and in particular to the critical need to give executives transparency into the status of a software project. Here’s more information about portfolio management and agile programming.
As Pat Durbin and Terry Doerscher write in Chapter 2 of their recent book Taming Change with Portfolio Management under the heading “The Elusive Nature of Knowledge Work”:
Knowledge work is difficult to plan, estimate, and complete. Unlike physical work such as construction or component assembly, knowledge-based activities are often one-of-a-kind endeavors with no direct historical comparison for estimating purposes. Knowledge-based work also lacks discernable indicators of progress.
The concept of Velocity in Extreme Programming, or Agile Programming, is an attempt to provide a discernable indicator of progress for software projects. It answers a simple but critical question for an executive of a software company:
How close to being done are we?
Therefore it allows the more interesting question to be answered:
What is the best compromise between what we want (our demand) with what we can do in a period of time (our capacity)?
Velocity is the amount of work completed by a team in a fixed, but repeating, period of time, called a Sprint. At Planview we use two-week sprints. However, the complexity of programming tasks, called Stories, varies widely, so you cannot simply count up the tasks. Rather, you measure the complexity of a completed task in an abstract measure. At Planview we call this measure Story Points, but you could call them “complexitrons” or anything you like. Every task must be consistently estimated in these Story Points.
If you measure the number of Story Points completed in several sprints by a particular team, you have the best measure yet devised for predicting how much work will be successfully completed in the next Sprint by that team. If you have all tasks estimated in Story Points, you can predict, with reasonable accuracy, when the project will be done. To an executive, portfolio manager, or project manager, this transparency enables good decision-making.
There are, however, some subtle keys to Estimation, Story Points, and Velocity that experience has taught us:
- The whole team participates in estimation.
- The estimate of a story must never change once it is decided. Time may show that the estimate is wrong, but to change the estimate is like telling a debtor he owes twice as much as previously agreed for no reason.
- A story may be split into smaller stories, but the Story Points, like money and energy and momentum, must be conserved.
- Estimates made quickly, relying on the ineffable thoughts of a skilled programmer, are about as good as detailed estimates.
- Expect velocity in any given sprint to vary about 40% around a multi-sprint average.
- Story writing is an art, but it is not a black art. A team and their product manager should be able to write 15 reasonable stories in an hour. Perfection is no better than “good enough”-ness. Do not allow the perfect to become the enemy of the good.
- When programmers disagree on estimates, resolve the disagreement by consensus and discussion.
- “Done” means “Releasable”. A task is not done until it is releasable. You may not be willing to ship a single story, but if that story is not done to the level of quality your customers demand, it just doesn’t count
![Product Portfolio Management in the Digital Era [Webinar]](https://blog.planview.com/wp-content/uploads/2017/09/Product-Portfolio-Management-in-the-Digital-Era-750x400.jpg)
![The 2018 Product Portfolio Management Survey Shines A Light on Top Performers [Video]](https://blog.planview.com/wp-content/uploads/2018/06/PDPM-study.gif)
