Technical Debt

We need to start recording our technical debt, I think.

For example, if Identity Server was a packaged third party product we’d be okay but it’s actually quite rough demonstration code with only a small integration test harness. It should be brought up to the same standard as the rest of the code base (eventually). So it works but we have a fair amount of technical debt that we need to record.

Note that we can’t use stories for technical debt. The debt accrued from getting a story to ‘done’ and the points have already been earned.

Also, as we are developing, there will be times we add TODO/HACK into the code but the story still meets its acceptance tests. This extra work should be recorded as tasks in the backlog and then ordered. A rough estimate in hours added to each task will reveal our technical debt.

There will be times when we deliberately let the code quality slip, usually by choosing to ignore some of our metrics going into the red, in order to make a release available. That technical debt needs to be recorded, too.

How we pay down the technical debt is another matter. Preferably we wait until we are revisiting that piece of work and have a need to refactor. If we have so much cruft in a piece of code that adding a new feature is risky then that’s another time when the debt needs to be paid down. Otherwise, let it accrue, debt is a useful resource in the project budget.

Easy to say, harder to do. 🙂

Planning Poker cards

We’ve been using ordinary playing cards for our Planning Poker game (Ace is one, King is thirteen) but it limited our range of story points so we’ve bought some cards from Mountain Goat Software that have everything from “?” to “∞”. Of course, now I want to try Team Estimation to see if we can speed up the Planning Meeting …

Making babies

If we keep metrics of how our Project Velocity changes as we add developers to the Team we can begin to get a rough estimate for how it will affect the Project Burndown.

In this blog post Mike Cohn estimates that adding a seventh developer to a six man team will reduce the velocity by approximately the amount you’d have expected it to rise by in the next iteration. In the second iteration following you will still be below your original velocity and it’s not until the third iteration following that you’ll gain your expected increase in velocity. Note also that the total gain in velocity will be less than ⅙th.

Any developer or project manager instinctively knows this and the reasons have been described clearly. For instance, there are four stages a team goes through: forming; storming; norming and performing ^[1] (Bruce Tuckman (1965)). More forcefully, there’s Brook’s Law: “Adding manpower to a late software project makes it later.” (or “Nine women can’t make a baby in one month.”).

Story Points vs. Hours for Sprint Burndown

I favour dropping the estimation of Tasks in hours for a Sprint. It’s extra work and it doesn’t add anything to the process.

• It’s proven that relative estimation is more correct than absolute estimation. Since ideal man days is a time measure it’s all too easy to make absolute estimations.
• There is no linear correlation between a story point and the number of hours. People who ask how they can correlate story points with ideal time have not yet learned to separate the concepts properly.
• A story point is a universal measurement across the team. It is not biased by the experience or skills of any individual on the team.
• In the spirit of continuous improvement Agile practitioners ought to be alert to opportunities to reduce their process overhead (without losing effectiveness).
• If each story is small enough to be estimated and tested then there may be little benefit achieved through breaking it down into smaller tasks or re-estimating them in hours.
• The return on investment by estimating in hours is not high enough to make that a serious candidate. We want completed, working software, not very accurate estimates.
• A Product Owner wants to know how many features the team will deliver not how many hours each of them take. If the Product Owner gets an idea of the relative size he can prioritise and plan accordingly.
• After the 3rd or 4th sprint, the team reaches a steady state in story points and it becomes easier for the product owner to fill the backlog with story points.
• It’s difficult and time-consuming to to get developers to estimate time to completion. Developers are terrible at estimating because the work they do isn’t the same each time: either it’s a new business problem or they are dealing with a new technology. Developers also have a tendancy to “hoard” left-over time: if they think they have been allocated so many hours to do something then the work expands to fill the available time.

Dropping hours means that in VersionOne the Sprint Burndown Chart won’t show anything at all but we can refer to the Project Burndown Chart and the Cumulative Flow instead as that burns down Story Points.

Planning Poker

Planning Poker is a fast, card based approach to team estimation. User stories are presented to the team and discussed as a group to round out understanding. In Scrum, this can be played in the Sprint Planning Meeting.

Rules

1. In the planning session each participant (player) gets a set of cards with the values 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity and ?.
2. One story is estimated at a time.
3. Each story is discussed briefly.
4. At the end of the discussion each player selects a card but doesn’t reveal his choice yet.
5. The cards are all revealed at the same time.
6. People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues. Often it is these discussions that reveal more aspects to be considered.
7. Repeat the estimation process until a consensus is reached.
8. If the average is greater than 20 points then the story should be split up and its parts estimated.

Additional Comments

All people who would work on delivery  are involved in estimation.

The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.

Avoid Anchoring where a stated opinion about the amount of time involved in a task can skew the rest of the team’s estimates.

It is important to remember the fidelity of most estimation input data is poor, i.e. we are usually dealing with approximations and best-guesses for work effort. Software development is difficult to predict and we get diminishing returns beyond a certain point of investing more effort in the estimation process.

Resources

There’s a good description of a Planning Poker session by Crisp.
There are free templates for the cards, for example, first page, second page.
The cards can be purchased from various sources but the cheapest are the originals from Mountain Goat Software, Mike Cohn’s company.
For distributed teams there’s a Planning Poker web-based application.

Agile Estimation, Mike Cohn

Here’s a couple of talks from Mike Cohn, who wrote the book, about Agile Estimation:
Bay XP Meeting Part 1: Agile Estimation, Mike Cohn
Bay XP Meeting Part 2: Agile Estimation, Mike Cohn