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 2

In the previous post of this series (Features balloon beyond initial estimates and don’t like getting done in this current Sprint – Part 1), I talked about the situation where a feature is taking more time than estimated; listed a couple of reasons for the same, and also tried to work out what are some of the possible alternate options that the team can take at this point of time. The previous post outlined one alternate option, where there were other features that were also required and the delay in completion of this feature was threatening the completion of the other features, and hence the team should take a break in the feature, split out the parts that are not yet complete or will not be complete (including testing) in the time period extension given for this feature.
However, there is a problem in this case. Just breaking up a feature in this case and moving the remaining part of the feature to a new backlog is not really recommended. After all, the feature was supposed to be done as per estimates and breaking it up and sending the remaining part of the product backlog makes everything very easy. Instead, every time this happened, the team needs to figure out why the estimates were not correct, and then take a hard call about whether they need to drop the remaining part of this feature, or ask the Product Owner to refine the feature to see whether all the essential items are done. And of course, if the team finds that they are getting into this kind of situation on a regular basis, then there needs to be an introspection which is much more detailed and which will go into this issue and find a solution. Such a discussion needs to be initiated and guided by the Scrum Master, but the expectation is that the team is the one which reviews the situation, tries to figure out the problems that are occurring and suggests solutions.
If the team gets used to a solution where the work can be split off and the work marked as Done for whatever has been completed, it leads to a precedence solution where the team (or atleast some of the team members) get used to the concept that even when the work is not complete, it is business as usual. Instead, the message that the team should learn and should adopt is that while it can happen that the work is taking more time than estimated, and there can be several reasons for the same, it is not business as usual. The team needs to work to ensure that such situations are not as a part of regular work, and how now to prevent such problems from happening again (atleast not for the same reason as why it happened for the first time). This is also necessary to ensure that there is confidence among the stakeholders, including the Product Owner. The idea is not to blame the team for such a situation happening, but in terms of reality, stakeholders get confidence only when they see that the team is doing some sort of introspection about why such a situation happened and what the team is doing to prevent this from happening again.

Read more about this kind of situation in the next post ..

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>