Q & A on Agile Portfolio Management

· by giulio · Read in about 2 min · (337 Words)

A while ago I held and internal session on Agile Portfolio Management. I found some questions interesting, so I share my answers here.

Q: How to measure the improvement of an agile Team, which indicator to use?

A: There are three useful values to monitor. One is the Team’s velocity: it should go up sprint after sprint, suggesting that the Team gets more and more efficient; the initial sprints are usually irregular.

Velocity

The second parameter is bug trends: the number and impact of bugs should lower as quality of the work improves.

Bug trends

The third and last indicator is the estimate accuracy: estimates at Sprint Planning tends to be more accurate as time (sprints) passes.

Estimate accuracy

All three indicators tends to stabilize in the long term: waste and errors reduces over time as illustrated by the following graphs.

Q: How to measure the costs of a Backlog Item?

A: A simple but effective way is simply to divide the number of Backlog Items completed in a Sprint by team Capacity for that sprint.

Q: Which approach to scale Scrum?

A: SAFe is a well-known proposal that has a discrete market acceptance. There is a good whitepaper on how to implement SAFe using TFS with links to introductory material on SAFe. It is also interesting to learn how other companies made the transition from a waterfall approach to agile methodologies, like Microsoft.

Q: Many teams do not complete their Sprint Backlog. What does it means?

A: This is a signal of improper Scrum adoption. The only solution is to better educate people. A good coach is the best solution, accompanied by some good reading like Mike Cohn’s books.

Q: I want to add an Effort field to get detailed costs. How?

A: Any Project Administrator can add fields, but it is important that it is coordinated with TFS Administrator as it may impact other Projects. A good tool to create roll-up reports is Microsoft Project Professional. There also other solutions, mostly involving custom code and therefore more expensive and fragile.