Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum: Features balloon beyond initial estimates and don’t look like getting done in the current Sprint – Part 1

This is one of those items that keeps on showing up in discussions that we have within the teams, and with other Scrum Masters (which of course means that their teams also run into these features from time to time). In an ideal world, the Product Owner has described the feature in enough detail in the Product Backlog, the User Stories for the feature have been well written, the teams have understood the features perfectly well, and the tasks are broken down in a way that each task can be done in less than 3 days. Of course, in reality, teams run into these problems all the time. There are can be a number of reasons why the estimates do not match the actual work needed, and all of them showcase that there will be problems and it is the hope of the team and the management that the frequency of these problems reduce over a period of time. Consider some of the reasons that could cause the estimate to be less than the actual requirement (and this is not a comprehensive list of the reasons for the same):
– The Product Owner did not define the requirement in a way that it was all clear to the team, and in the estimation meeting and the actual estimation, this lack of clarity was not apparent, becoming clear only when the work was happening
– The developer who actually made the estimate did not manage to provide an accurate enough estimate, could be because of lack of competency, could be because of design issues that were not apparent during the estimation, could be because of defects during the actual development process, and so on. There could be a number of reasons about why the estimates of the development team were wrong, and some of them could be traced down to learning issues rather than incompetence
Now, what happens when you run into a situation where the feature is taking more time than estimated. Obviously, this has a ripple effect on other features planned for the Sprint, and you need to figure out what the options are. The people to discuss this and come out with a conclusion are the Product Owner, the Scrum team, and the Scrum Master. There are several options that the Scrum team can follow, with the actual option that needs to be followed by the Scrum team depending on the exact situation of the Scrum team. Here are some of the options:
– The feature that is currently being worked is not the only feature that is important in the Sprint. There are other features that are also planned in the Sprint, and spending more than a couple of days extra on the current feature will prevent the completing of other features in the current Sprint. If this is the kind of situation in place and the Product Owner has made that clear, then the only option is to quickly close down the current feature once it starts impacting the other features. Based on the amount of work done, it is required that the team make a logical break in the current feature, split off the parts that are not yet done into an additional feature (and provide the relevant information in the new feature so created). There is a special case where the delay caused by the engineering team is such that the feature was completed from the development team but is not giving enough time for the testing team. In that case, it needs to be estimated as to the amount of work that can be tested in the given time, and branch off work that has been done beyond this point. It seems harsh to move completed development work into the future, but unless more testing effort can be found or the impact on forthcoming features is discarded, it is necessary to do.

Read more in the second post in this series (Features balloon beyond initial estimates and don’t look like getting done in the current Sprint – Part 2)

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>