Scrum: Sprint planning

Posted on 2 CommentsPosted in management

Information below is from „Do Better Scrum“ – special tips and insights. You can download it from http://www.scrumalliance.org/ I just want to use it for references in my posts 🙂

Sprint Planning – Part 1
Part 1 of sprint planning (SP1) is really a detailed requirements workshop. The product
owner presents the set of features he would like and the team asks questions to
understand the requirements in sufficient detail to enable them to commit to delivering
the feature during the sprint. The team alone decides what it can deliver in the sprint,
taking into account the sprint duration, the size and current capabilities of its
members, its definition of DONE, any known holidays or leave days and any actions it
committed to during the retrospective held just prior this meeting.

The product owner must be present during this meeting to lead the team in the right
direction and to answer questions—and they will have many. The ScrumMaster must
ensure that any other stakeholder needed to help the team understand the
requirements is present or on call.

Any new backlog items for inclusion in the current sprint and not previously estimated
will be sized immediately during this meeting. This not, however, an excuse to avoid
grooming the backlog

At the end of SP1 the team commits to the Product Owner what they believe they can
deliver in the form of running tested features. An experienced team may use historic
velocity as a predictor (‘yesterday’s weather’). This is known as velocity-based
planning. My recommendation to most teams is to do commitment-based planning.
The backlog items the team has committed to is called the selected product backlog.

Sprint Planning – Part 2
If part 1 is a requirements workshop, part 2 of sprint planning (SP2) is a design
workshop. In this session the team collaborates to create a high-level design of the
features it has committed to deliver. An outcome of this session is the sprint backlog,
or the list of tasks that the team collectively needs to execute in order to turn the items
in the selected product backlog into running tested features. This set of tasks is called
the sprint backlog and is most often represented on a physical task board.

During SP2 the team may have additional questions regarding the requirements. The
Scrum Master must ensure that the Product Owner and, if necessary, other
stakeholders are on call to answer them.

Design, as everything else in Agile, is emergent. Also, the meeting is time-boxed. So it
is normal that the team won’t get the design perfectly done in this session and will
discover more tasks during the sprint. This is not a sign that something is wrong. They
will simply grab a post-it note and pen and create more tasks whenever necessary
during the sprint.

Notes

  • You will know that SP2 is working when the team is gathered together around the white board discussing noisily or even arguing about the ‘best’ or ‘right’ way to implement a feature.
  • Never do sprint planning on a Monday morning. The team is not yet at its best and it is the most common day for holidays and sickness. Never hold reviews or retrospectives on a Friday afternoon. The team is tired and thinking about the weekend. Therefore choose sprint boundaries on Tuesdays to Thursdays.
  • Teams running two-week sprints might be tempted to hold all sprint boundary meetings in one day. In other words, start the day with the review, then the retrospective; after lunch do sprint planning parts 1 and 2. The thinking is to get all the meetings out of the way and have 9 full days to do the work. In my experience there are two problems with this approach:
    • The team does not get that these meetings are part of the work—in fact the most important part to get right!
    • During the last part of the day—sprint planning 2—the team is brain-dead.

Yet, as always, let the team try it out if they so wish!