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.

Planning to ensure that the Sprint Planning meetings work well as a part of the Scrum process – Part 1

The Sprint Planning Meeting is a critical component of the Scrum process, whereby the team takes a prioritized list of features, and then breaks down these features into tasks, estimates these tasks, assigns them, and forms a Sprint backlog such that the tasks are tracked through the duration of the Sprint. For this to happen, there are a number of different activities that need to come together to ensure that the Sprint planning meeting is effective and helps in delivering a list of tasks for the Sprint cycle. Some of these activities are:
– The product owner should be very well prepared for the Sprint planning meeting, should have a prioritized list of features available, such that the top ones can be selected for the Sprint (and this also means that all the external inputs should have been taken to ensure that the prioritized list of features is indeed reflecting the current market and competitor trends). However, this is not a one time thing, with updates to the priority listing of the features / user stories being available to the Scrum team to review at a regular basis (through the use of some tool, or through an updated chart near the Product Owner’s office)
– The Product Owner should be able to explain the user stories, and be able to comfortably answer the questions asked by the team (very important since the estimation done by the team for the user stories / tasks breakdown is based on the answers received from the Product Owner). Ideally, for every Sprint, there should be an end goal (such that the majority of user stories in the Sprint cycle are geared towards this goal) which is also spelt out by the Product Owner during the Sprint planning meeting, since this helps in delivering the perfect context to the Scrum teams
– Once we have the details of the user stories, the team next needs to work on the total capacity that they have so that the Sprint Backlog for the Sprint can be worked out. This capacity should take the total size of the team, set aside efforts for non-Scrum tasks such as maintenance, support, and others (or maybe classify them as a separate Sprint story – the miscellaneous story), also capture the vacation times currently known for the different team members, and then take the remaining number of days combined with a planned number of hours per day (teams are known to take between 6-8 hours). This is something that becomes more clearly defined with experience, but the guideline is that it should not be too aggressive.
– The next step is when the team starts to break down the various user stories (as presented by the Product Owner) into separate tasks that can be estimated, and of course the task estimation is an altogether specific effort, with a lot of teams using concepts of Planning Poker (combined with Fibonacci cards) for the purpose of estimation, and the actual estimation can be an iterative process for some of the tasks as different estimates by different team members are reconciled.

In the next part of this article, we will look at more details on the Sprint Planning meetings.

1 comment to Planning to ensure that the Sprint Planning meetings work well as a part of the Scrum process – Part 1

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>