Scrum: Sprint planning

Information below is from „Do Better Scrum“ – special tips and insights. You can download it from 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.


  • 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!


2 thoughts on “Scrum: Sprint planning”

  1. Pingback: How do you ensure that commitments are delivered? « Ideas « Agile Mindstorm

  2. Let’s step back and look at the problem(s) arcurtecthie is supposed to solve (I may be completely wrong here, so feel free to correct me) * Reduce waste from rework * Increased changeability of code by avoiding writing frozen codeBoth of these are incredibly important in an enterprise with hundreds of developers working on interoperable systems.Traditional enterprise arcurtecthie tried to accomplish this with architects as gate keepers. They would somehow be responsible for the design of the entire arcurtecthie of an organizations software system, but be so involved in meetings that they wouldn’t get much opportunity to see how the code is actually interacting. Decisions which make perfectly rational sense at the architects abstraction layer could cost a lot of money and not provide any additional business value.Agile arcurtecthie requires architects to act as empowerers instead of gatekeepers. Their responsibility isn’t to prevent poor design choices, but to use their experience and skills to create communities of shared does this happen?First, they must focus on making important information big and visible. * Code health (however you measure it) * I prefer to measure cyclomatic complexity and unit test coverage, and monitor for improvement over time as opposed to some absolute mandated metric. * Public API Specification * I prefer to use a tool like cucumber to create human readable examples exercising the public API.This is more difficult than it sounds. Making this information big and visible is *TOUGH*. The best way’s I’ve seen have involved using tools like github corporate accounts so that the wiki, build instructions, issue tracker, and source control are all tied into a single streamlined (yet highly adaptable) systemSecond, they must focus on providing the right education * The 4 rules of simple design are pretty crucial * So are code smells and refactorings * What are the common values you share as a dev organization (Small parts loosely joined? Boy Scout?)Flipping architects from gatekeepers to empowerers is by no means an easy task. It requires a hig level of respect and empathy from all involved parties, and a willingness to trust that everyone involved is doing their best to help the organization succeed.

Comments are closed.