How do you determine velocity when the previous sprint was half User Stories and half Defects?

Question

The following scenario often happens with my team at the office. Let's say we decided to plan our Sprint this way:

• 50% new features
• 50% bug fixing (they are high priority AND unestimated as the fixes are easy, the hard and time-consuming bit is the investigation)

The Sprint goes well and we finish all the features, say X story points, and quite a few unestimated bugs.

Two questions come to mind:

1. What is our Sprint velocity? Is it X?
2. Assuming it is X; how do we plan the next Sprint using "yesterday's weather" (X story points) if we now want to do an 100% new features Sprint?

Answer 1

Velocity is X because velocity measures how much story points (= business value) you delivered in the last sprint. But you have second value available - capacity. Capacity is number of hours / man days you have available for the sprint. So if you now doubled the capacity you can assume that your velocity will increase. It is up to team to judge if doubling the capacity will double expected velocity. Of course not every increase in capacity will lead to increase in velocity. For example adding team member will definitely not have immediate effect of velocity increase (the reverse is usually true for few sprints).

If your capacity change frequently by large amount of hours / man days it will affect average velocity value and its meaning for forecasting will be much worse.

Btw. 50% time spend on bug fixing should raise some questions about the way how you deal with quality of your product = how you create your automated test suite.

Answer 2

Add the time spent on fixing bugs in a story to the time spent developing the story (because actually the total time you spent on developing the story includes fixing the bugs: the story was not acceptable to the product owner in the buggy state). Now that is an indication of your velocity.

Answer 3

All the tasks which are completed should be assigned some type of estimate. These estimates can be in time, user stories, or some other unit.

Upon completion of the sprint, you'll know which tasks were complete and which weren't. Even if some of the tasks were to fix defects, that is still considered tasks that were completed.

You can use this information to gather your slope. From here, you'll be able to apply this to a burn-down chart and get a percentage as to when you'll be down with the project at hand.

Finally, bugs created during a sprint should be fixed before the end of the iteration. A task should not be considered done if it had outstanding bugs in a sprint.

Answer 4

If the discovered defects are not related to a currently active story, the defect prioritization and estimation should be part of sprint planning.

Prior to planning, the team can assign points to defects in the same way they assign points to features, which will allow the product owner to prioritize defects in relation to features. The time required to investigate and resolve defects should be defined as tasks associated with the defect.

It's really crucial that the product owner be made aware of the level of effort required to resolve each defect so he/she has has a clear picture of what is going on. I would hesitate to allow a philosophical debate on the definition of "velocity" get in the way of this.

However, if you're trying to show management that a high defect rate is impacting the rate at which you deliver features, you can always show this via defect counts or defect/feature ratios.

I think this would be better than showing declining velocity without explanation.