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.

Trying to force features to end in a specific Sprint because of team pressure

In the previous post (Feature not ending in a particular Sprint), I talked about how if a specific feature is not completed in the time for the Sprint demo (and this completion may not be happening because of incomplete development or incomplete testing or some other reason), then it should be moved to the backlog for incorporation of the next Sprint. This is the correct step to take, since if the feature is not complete, then it should not be placed ready for demo in the current Sprint. The Scrum process, something which is explained to the team, and which seems to be a very valid constraint, talks about how only those features should be taken in the Demo and marked done, which are actually done.
However, there can be problems with this approach. When team members have spent a fair amount of time with a feature, including on the development as well as the testing side, there is a sense of ownership and attachment with the feature and a quest to ensure that the feature is marked done. So, there could be discussions about how the remaining defects to be fixed are minor, about how the work that has been done is major and the remaining task that is pending is minor and could be split off into the backlog, and similar such objections. And given that this an empowered team, with the Scrum Master not having any authority to make decisions (but rather expected to guide the team into making decisions), if the team feels strongly that the feature needs to be marked done, then it can get tricky.
So, the scrum master needs to lay out the options for the team and guide them through the decisions. Owning the backlog is the authority of the Product Owner and quests about splitting up features into major and minor parts is upto the Product Owner to decide. A Product Owner may decide that the extent of work done which is upto Done quality can still be used and the other parts can be split off, or can decide the other way. However, this is where the Scrum Master needs to make a mark, working with the Scrum team to define the possible options, the pro and cons of every decision and trying to get them into a point where they take the right decision. This can be tough, and it can be difficult to overcome the resistance of team members who have put in a lot of effort into a feature, but in the end, the success of the Scrum effort is dependent on the Scrum team taking the right set of decisions. It would be wrong for the Scrum Master to try to insist on a particular decision, since that would start to impact the ability of the team to make the tough decisions.

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>