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 – Evaluating estimates when the Product Owner seeks to add new items during the Sprint

Many of you would have seen something like this. The Sprint has started, there are items that have been estimated and the Daily Scrum stand-up meetings are happening, and everything seems to be going right. And guess what, this is the time when the Product Owner comes in and basically says that there are some emergency requirements that came up and which need to be taken in the current Sprint. Now, these can be new features, or they can be modifications of existing work already planned for the Sprint. If it is modification of existing work, the Product Owner will come in and essentially state that this should be a minimal change and it would essentially seem like swapping of the work that is already planned. However, this is the wrong way to go about this process. Any change is a change and needs a strategy to deal with it.
First of all, the team (including the Product Owner) should have a base strategy about how to deal with change. I know of one team which came to an agreement that short of something catastrophic, they will not change work planned for the current Sprint, since the Sprint cycles were only 2 weeks, and the planning for any change was very disruptive. In this, they had the agreement of the Product Owner once he understood the impact of any change. However, it is not necessary that every team come to such a sort of arrangement. In many teams, the discussion in the team does veer towards letting the Product Owner decide whether the change is necessary or not, but the team retains the right to decide the impact to the existing schedule caused due to the change.
In our cases (the multiple scrum teams in our organization), most of them have come to the agreement that no matter what the change, the team will not make any change in the middle of the sprint without doing a re-estimation of the new requests, and also evaluating the impact on existing features (including even of the time taken to discuss the new requirements with the PO, understand them, and then do the estimation). There were some Product Owners who were not comfortable with this approach, since they considered themselves the drivers of whatever the team was doing, and it took some amount of discussion and delineation of the effort involved in taking changes before everybody was agreed to upon this matter. However, from time to time, different stakeholders did point out new issues that were critical and wanted the team to take these changes without any impact, and even though the team did make a best effort, no feature was taken in (either added or modified) without doing an impact analysis on the change it would cause to the current Sprint. Overall, the team felt that more exposure in terms of knowing the impact of such changes was desirable, and was a part of best processes, and there was overall support from management on this.

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>