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.

Dealing with new requests raised by the developer during the Sprint – especially with new teams

One of the problems that come up when dealing with new Sprint teams is the lack of discipline when it comes to making changes during the cycle. For teams that have a fair amount of experience with the Scrum methodology, it is fairly clear to them that the Sprint planning is such that there are a defined set of user stories laid out by the Product Owner, they need to estimate the tasks for these user stories and ensure that they have clarity on what the user stories mean and the tasks that would be needed to complete these user stories. When you have teams that reach this level of performance, they have a high level of productivity.
For teams that are somewhat new to Scrum, most of the team members would be used to the Waterfall method of software development, and there the concept of a Sprint is not something that seems familiar; and more so, the concept of a new requirement coming up in the middle of the Sprint. This was something that was a struggle with the teams (and especially the ScrumMaster) for teams that were new to the implementation of Scrum.
So, as an example, we had people in the team who were used to doing a very rough estimation in the beginning, and then refining their estimates once they were actually getting the work done; this was easy to do since it meant less effort during the estimation stage and since it was not normally challenged later when the actual coding was ongoing. However, when this was observed during the Sprint, it caused problems. The Scrum Master let this new task(s) be added to the work for the Sprint, but in a specific case, the amount of work so involved caused another task to get moved out. This was an important task that was expected from the Sprint, and that is when things got more serious.
So, from the next Sprint (actually in the previous retrospective), we seeded the idea for the discussion about why the task could not be done for the current Sprint and let the team members take the lead in the discussion. Gratifyingly, the developer who was responsible for the extra tasks was the one who took a critical part in the discussion and the discussion finally moved towards the direction of ensuring that tasks are estimated properly during the initial stages. The next time we did the Sprint planning, there was a renewed interest in ensuring that tasks were properly broken down from the User Stories defined by the Product Owner, and then these were discussed and estimated.
This development led to much greater responsibility from the team members, and a much higher productivity level; we went through ups and downs, but in the future, we did not come across a case where we missed a task because the estimation was not done seriously.

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>