This is a series of posts that focuses on the problem where in a Sprint, the feature does not match the estimates (and it’s not that the feature gets done before the estimated time). For every Sprint, there are a certain number of tasks that can be done, and these are based on the estimates that are given by the Scrum team members during the initial Sprint planing meetings. However, when there is a significant difference between the estimates and the actual time being taken for the feature, then there are implications. Besides trying to work out the reasons for the difference between the estimates and the actual time needed, the team also needs to work out what this means for other features that are planned in the Sprint. In the previous post (Features balloon beyond initial estimates and don’t look like getting done in the Current Sprint – Part 2), I went through the case where the team decides to break up the feature and do the other parts in a future Sprint, and the impact of this on the team and on their credibility.
This post looks at some other alternate course of actions, depending on the situation of the team, the critical nature of the pending features, and the overall decisions made by the team. In the previous post, it was determined that the team needed to make sure that the remaining features needed to be done (or atleast some of them needed to be done) and so the current feature was stopped at that very point of time. However, there are other courses of action that could be taken. Let us look at them:
– The main other course of action could be that the Product Owner really needs that feature to be done in the Sprint cycle, even if there is a ripple impact on the other features planned for that Sprint cycle. The feature could be needed for a press review, or to show to clients as a major example of progress, or the Product Owner is so interested in the feature that he or she really does not want to break it up. For that purpose, as the Sprint cycle moves on, this particular features and the other features on which work is ongoing will continue, and newer features can be taken up depending on the amount of time and resources left.
The features that are not done in the current cycle will need to be taken up for the next Backlog, but like in the previous post, it cannot happen that work is as normal. When feature estimation does not match the actual effort, the team will need to introspect about the reasons for the same, and treat this like an occasion for learning, to figure out why the estimates did not match. For some of the team members, this may not be apparent, and the discussion that hopefully finds the reasons for the mismatch also provides a learning experience for those team members who do not have the required experience. It is absolutely necessary that the team reviews the problem (especially when the discrepancy is large, or when there a number of items where the discrepancy exists).
Read more about this in the next post.