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:
- What is our Sprint velocity? Is it X?
- 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?
Best Answer
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.