Sometimes, a team has a zero or low velocity because of obstacles that prevent them from delivering running, tested features. In that case, ask the team to measure those obstacles.
Measuring obstacles might seem like a strange thing to measure. “JR, I don’t have space for a standup meeting. How that heck do I measure that?” But you can measure obstacles. If you’ve asked for space for a
MEASUREOBSTACLESPREVENTING THETEAM’SPROGRESS 150
standup and you can’t get it, you list the obstacle and how long it has been since you asked for space.
Jan 7 Standup meeting
area with whiteboard
38 44
2 Need tester full Jan 1
time
Feb 1 Chair for Jim
1 15
Days Since Request Date Request Date
Obstacle Rank
Obstacle Report
Any time a project team doesn’t get the resources it needs, it won’t be able to deliver the value your managers thought it would when you ranked it in the project portfolio. If you track a top-ten risk list, you could use that as your obstacle report.
Project managers: don’t put more than ten obstacles on your report.
You will overwhelm your leadership team, and they will either ignore you or try to solve those problems in the portfolio evaluation meeting.
You want your sponsor or someone from the leadership team to work with you to remove obstacles. Ask for help outside of the project port- folio evaluation meeting. Leadership team: if you see an obstacle report with more than ten obstacles, you have a team in trouble. Pay attention to them. They need help. Get them what they need.
But the more interesting obstacles are the ones measuring technical debt. Those can be defects, a lack of automated tests, or product-based technical debt. For defect charts, see the charts in Manage It![Rot07].
This technical debt chart might be a way to show other technical debt in the product. You might see evidence of technical debt in the speed and frequency in which the project team finishes stories.
MEASUREOBSTACLESPREVENTING THETEAM’SPROGRESS 151
Effect of Technical Debt on Iteration Output
0 2 4 6 8 10 12 14 16
1 2 3 4 5 6 7 8 9 10
Iteration
Story Points
Expected Story Points Per Iteration
Story Points Complete
Once people can see that the project team is working more slowly because of technical debt, you can put a dollar amount on it, which you can use to decide whether paying off technical debt is worth more than some new features.
Here, the project team is not keeping up with the expected number of automated tests, leaving a debt for this iteration of thirty-four auto- mated tests. Is that a big number? I can’t tell. Maybe it’s a business decision. Maybe they estimated wrong. Maybe they need those tests, and they are going to have trouble in a future iteration. Right now, you can’t tell anything from the data, except that it’s time to ask more questions.
Effect of Automated Test Technical Debt on Iteration Output
0 5 10 15 20 25 30 35 40
1 2 3 4 5 6 7 8 9 10
Iteration
Story Points
Expected Automated Tests Actual Automated Tests Automated Test Debt Accumulated Test Debt
In this case, the technical debt is caused by a lack of some automated tests and a lack of redesign of older code. The technical team wants to add some automated tests, but the product owner wants more features.
MEASUREOBSTACLESPREVENTING THETEAM’SPROGRESS 152
(Yes, some agile teams leave allproduct backlog decisions to the prod- uct owner.) Once the product owner sees that the team is capable of supplying only about two-thirds of the story points for the same time, the product owner is more likely to change the items in the product backlog to include more technical debt items. But if the product owner doesn’t, management can.
As a different example, in the following figure the team has an ini- tial zero velocity in the iteration—they finish zero stories until the last week of an iteration. Not all teams finish stories at the same frequency throughout an iteration. But not finishing any stories until the last week of the iteration is an indication of a problem and could be techni- cal debt. There are other reasons, such as too much work in progress or that the team is using a too-serial approach inside the iteration. Using a chart like this one is a way of making the problem transparent so the team can do something about it.
Stories Remaining to Complete at Day of Iteration
0 2 4 6 8 10 12 14 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Day
Stories Remaining to Complete
# Story Points Left to Do
If you’re working on a legacy product where you know you have techni- cal debt, the earlier you can measure it, the easier it will be to address the debt in the backlog or in the project portfolio ranking and, by infer- ence, how many people are assigned to the project. If you’re working on a project team that’s new to agile, you might want to measure technical debt so you aren’t surprised by what “done” means. And, if you’re on an experienced agile team, you can prevent waste in the organization by being proactive about looking for and paying off technical debt.
If you need some other ideas about how to measure technical debt, consider the following: the percentage of automated test code coverage for each feature set, a McCabe’s metric for each of the highly complex modules and the time it takes to make any change in those modules,
MEASURE THEPRODUCTBACKLOGBURNDOWNCHAR T 153
and how quickly the team completes stories inside an iteration. A num- ber of static analysis tools can help you discover what’s going on in the code. You might find there are other measures you want to take; these are just examples.
However the project team decides to show their obstacles, make sure you ask about them. Their obstacles will prevent them from making progress and may require more people or more time for the project, which might change its rank in the portfolio.