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.

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

In the previous post (Sprint Planning Meeting – Part 1), I talked about some of the points that people need to take care of during the Sprint Planning, including some of the responsibilities of the Product Owner, calculation of the total available capacity of the team for the Sprint, and then breaking down the user stories into smaller components. In this post, we will talk more about what it takes to make the Sprint Planning meeting successful.
– A lot of teams actually ask the Product Owner to leave when the Sprint team is breaking down the user stories into much smaller tasks that need to be estimates; the reasoning goes that the team would need to break down the features into tasks without any influence from the product owner, but the product owner should be somewhere where he or she can be called quickly for clarifications or other such details.
– Setting a Sprint Goal. A Sprint Goal sets the team a broad target for the overall effort, something that is achievable; even in the case when all the tasks slotted for the Sprint have not been met (this ensures that there is some flexibility in the entire system); what is equally important is that the Goal should not be laid down to the team, instead the team should be involved in the decision making to select the Sprint Goal. There are many advantages of the Sprint Goal such as ensuring that everybody is on the same page with respect to the features, ensure that features working towards the goal are selected for the Sprint, and also ensure that the broad goal can be sent to all the external stakeholders.
– We need to spend some time on the task definition. A task needs to be defined in a way that it is easily testable, feasible, and also fairly small that they can be done in a short period of time (it does not work if you define tasks in a way that they extend for long periods of time). The item needs to be clearly testable with clear parameters set for failures and successes.
– The prioritization needs to happen such that it takes care of dependencies and infrastructure needs. For example, if other teams depend on a task that this Scrum team needs to do, this needs to be factored in the prioritization (even if the importance of the task to the Scrum team is not so important). Similarly, if there are tasks that are needed for design or other infrastructural purposes, then the priority of these also needs to be set properly.
– Set a defined schedule for the meeting that consists of defining the separate items that need to be covered in the meeting, the purposes of each of these items, who will be driving these items, the documents that are generated from these parts, and also the defined time interval of each of these activities. These activities are:
Calculate the capacity for the team
Product Presents the various stories and answers questions
Team breaks down the stories into smaller discrete tasks
Team commits to these stories along with estimates, ready to start.

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>