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.

Ensuring some time in the current Sprint for planning for the next one

We were having a discussion with a few project managers about one of the biggest problems that we could see in terms of usage of the Scrum model for some of our teams / products, especially the ones that were more complex. And then we realized that the problem was not with the Scrum process per se, but with some of our implementation techniques, and that a few of the Scrum Masters had finessed the technique and learnt how to overcome some of these issues. So what was the issue ? Well, when the team went in for a Sprint, there was no preparation done in advance of the Sprint for the work to be done in the Sprint. As a result, if the work was complex or had some dependencies on other work, it was not fair to just throw this to the development team at the time of the estimation, there was a real need to have done some discussions with the team already prior to working on the Sprint.
Another problematic area was about where the work required UI work, and it was not easy to suddenly have the UI work and the actual implementation being done in the same Sprint. This is more important when there are technical limitations in terms of fulfilling the needs of the UI / workflow designer. It is important to have some engagement prior to the actual Sprint since this ensures that the team has already had a bit of fine-tuning in terms of the User stories or the requirements that will be laid down in the estimation time period.
So how does this actually happen ? Well, in the Scrum style of development, no work should happen without it being accounted for in the actual Sprint. So, in order to do this trade off, some of the work planned for the current Sprint is reduced to do the planning for the next Sprint. The teams that I know that have done this sort of work actually do some amount of estimation of the work required to plan for the next Sprint in terms of activities and tasks and actually add them to the current Sprint.
So, there is a dichotomy since some of this work cannot be demoed at the end of the Sprint, only the plans or design or whatever else has been defined at the end of this activity can be shown to people. But the advantage of having these kind of activities happening in the current Sprint were pretty immense in making sure that the work happening in the next Sprint was better planned.
One caveat is that this should only happen if the work for the next Sprint is likely to be so complicated that it requires this kind of pre-work or that there is such a lot of iterative UI work that it would not be feasible to do this work all of a sudden at the time of the next Sprint.

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>