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.

What to do when a feature does not end in a particular Sprint ?

We would all have seen those cases in teams which are using Scrum. If you are using Waterfall as your development methodology, and if a feature gets delayed either in the development or testing end, the feature tracking in your MS Project schedule will slip. So what do you normally do ? Well, depending on whether the feature is only slightly late or significantly delayed, you decide your course of action. If the feature is very important and significantly late, you will have to delete some other features that are not so important, and there are other courses of action dependent on the critical nature of the feature and also about how late it is. In a number of these cases, you can incorporate the change in schedule of the feature by modifying the schedule, even though it will push out some of the features to come after that (in your schedule tracking app, I use MS Project).
However, the case is not the same in teams that are using Scum as their development methodology. Teams they divide the project into multiple Sprints, with the length of each Sprint being similar to each other. The idea is that in each Sprint, the Product Owner has laid out the list of features / User Stories in a priority order and the team keeps on estimating the features in that order until they reach a point where there is no more effort available to ensure that the feature is done in that Sprint. Now, done is done; an odd statement, but it simply means that when the Sprint is done, the team should be able to provide a demonstration of that feature to the Product Owner and to the other team members, and also that the development and testing of that feature has been completed.
However, what happens when you have a feature that is not going to be totally completed in the Sprint. There might be some critical defects pending to be fixed, or there might be the entire testing to be completed, or the development of the feature may not have been completed. The reasons for these can be varied – the estimates were not correct, the number of defects found were more than expected, the test cases written for the feature were inadequate and new cases had to be tested before the feature can be marked done, the development of the feature was more complex that expected, and so on. Now the team has a feature that they have worked on during the Sprint cycle, and are unsure of how to treat the feature.
The solution is very simple. The feature is not completed during the sprint cycle, and should not be marked for demo in the current Sprint Cycle, even if there are feelings for marking the feature done (based on the attachment that the team members have generated after putting in effort). It needs to be put back on the Backlog for consideration in the next Sprint. The estimate for it would be lower than it was in the previous Sprint, since some amount of effort has already gone into the feature and if selected, the feature can again be taken up by the team. However, I have seen a case where the Product Owner took it out of the backlog (or rather, reduced the priority for the feature), since there were more important features marked for the next Sprint and they needed to be completed for the overall benefit of the product. There were some feedback from the team for this decision, but the Product Owner had a small meeting to explain the need and also to re-emphasize that decisions are taken for the overall benefit of the product.

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>