Sprint planning in Scrum

At our last retrospective, the Vision Tasks team decided to restructure our sprint timetable. With our two-week sprints running from Monday to Friday, it felt disjointed holding the end of sprint review and retrospective on the Monday morning of the new sprint; sprint planning was then squeezed into a one-hour slot on Monday afternoon.

With the new timetable, the sprint review and retrospective are now held on the afternoon of the last Friday of sprint. This should help us round off the sprint nicely without the hiatus of a weekend. But it also frees up the whole day on the first Monday of sprint for planning, which is what I want to explore in this post.

Planning in two acts

During sprint planning the team is asked to answer two questions:

  • What can be delivered during this sprint?
  • How will this work be achieved?

These don’t need to be separate meetings but what is important is that both questions be answered: what then how.

In my experience, new teams often only answer the ‘what?’ They drag enough stories onto the sprint backlog to match their velocity then kick-off the sprint with no real sense if what they have committed to is achievable or not.

The ‘how?’ part takes all the Scrum values to work at and perfect: commitment, courage, focus, openness, and respect.


There are three things required going in to a sprint planning meeting

  1. a refined, prioritised backlog.
  2. an understanding of the team’s velocity, that is how many story points a team can complete in a sprint.
  3. an understanding of the team’s capacity for the next sprint, in hours.


When working out the team’s capacity for development work, each team member should take the total number of hours for the sprint (number of days × hours worked, e.g. 10 × 7 hours) minus any time spent in meetings (daily scrum, backlog refinement, sprint review, sprint retrospective and planning).

Then deduct an hour or two of ‘slack’ for each day to account for dealing with email, distractions, requests from other teams, etc.


The Scrum Guide sets aside a maximum of eight hours for a one-month sprint with a recommendation that shorter sprints are proportionally shorter. So, around four hours for a two-week sprint.

Part 1: What can be delivered during this sprint?

During the first part of the meeting, the product owner presents to the team the next-highest priority items on the backlog. Using the team’s velocity as a guide, the team estimates how much work they think they can deliver during the next sprint.

It can be helpful to keep an eye on the team’s definition of ready to determine whether stories are ready to be pulled onto a sprint, and the definition of done to be clear about what will need to be done to deliver it.

If any new information or insights have come to light, this is the last opportunity before the sprint starts to re-estimate any stories.

Part 2: How will this work be achieved?

Where I have found many teams go awry is that they have misunderstood the Agile Manifesto’s statement about “responding to change over following a plan” to mean “don’t have a plan”. It surprises them to learn that actually more planning is asked of them.

User stories, remember, are not requirements. While they represent user requirements they don’t document them. They are reminders to have conversations to figure out what needs to be done and how to do it. That conversation starts in backlog refinement and gets continued in this phase of sprint planning.

“To acquire confidence in what it can get done, many development teams break down each [user story] into a set of tasks […] The development team then provides an estimate (typically in hours) of the effort required to complete each task. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the features done.”

— Essential Scrum by Kenneth S Rubin (Addison Wesley, 2013)

It’s up to the team how they do this but each story should be examined one by one, tasked-out and estimated in ideal hours. You may wish to break the team up to focus on particular areas of speciality, or you may wish for the whole team to discuss everything.

There are many benefits to this approach.

First is the wisdom of crowds. Because everybody is invited to contribute their experience and insights into every story, each story benefits from the input of the whole team about how that feature will be built, tested and delivered.

Newer team members get exposure to parts of the application they may not have encountered yet and can ask questions for clarity.

In thinking each story through at a deeper, more practical level, it can reveal things that had not yet been considered. There might be a realisation about the order certain stories need to be worked on. Anything useful that comes from these discussions should be recorded on the card so they are not forgotten.

Because every team member has helped think through every story, if someone unexpectedly goes off sick, other team members can step in to take up the slack more easily.

It is also easier to manage team capacity at this point than during the sprint. Once stories have been tasked-out and estimated in ideal hours the team can figure out who would be best suited for each task. The duration of those tasks then gets deducted from the team members’ capacity totals until there is assurance that everyone on the team has enough work to do during the sprint.

If there is clear shortfall or over-commitment, then the sprint backlog can be adjusted as appropriate: push items back onto the backlog or pull over more, break them down and estimate them.

At the end of this phase of the whole team should be clear about what the sprint goals are and how they will be realised.


The final ceremony during the sprint planning meeting is for the team to vote on how confident it is that it will deliver its commitment. This can be done using Planning Poker™ cards or simple finger-voting, showing one, two, three, four or five fingers depending on one’s level of confidence.

If the team are confident they can deliver everything the sprint begins. If not, they can explore why and make adjustments as appropriate.

Things will change, the team will discover things they hadn’t considered or couldn’t see at the time. Some tasks will be harder than they expected. Others will be simpler. But by taking the time to work together to plan as far as they can see, they set themselves up well for success.

Originally published on the Vision internal blog.

Be agile not Agile™

In 2014, Dave Thomas, one of the seventeen who met at Snowbird ski resort in Utah and came up with the Agile Manifesto, wrote a blog post with a wonderfully clickbait title: “Agile is dead (long live agility)”.

In the article he laments that too many people focus on ‘Agile’ with a capital ‘a’ as though it was a brand: Agile™. Agile isn’t a noun (a naming word, my primary school teacher would drill into us), agile is an adjective (a describing word). Thomas urges us to think about agility not Agile.

“The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.” — Dave Thomas

Agile principles

I’ve been thinking a lot recently about agile principles. What are the fundamental truths that serve as the foundations of agile development—sorry, of development that shows agility?

Agile manifesto

Of course we have the Agile manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

“That is, while there is value in the items on the right, we value the items on the left more.”

Scrum values and pillars

Scrum has five core values:

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect

and three pillars

  • Transparency
  • Inspection
  • Adaptation

AgilePM (DSDM) principles

I’m fond, too, of the eight principles on which AgilePM (formerly DSDM Atern) is built:

  1. Focus on business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise quality
  5. Build incrementally from firm foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate control

Bertrand Meyer

Bertrand Meyer in Agile!: The Good, the Hype and the Ugly (Springer, 2014) argues for the following principles that promote agility:

  1. Put the customer at the centre
  2. Let the team self-organise
  3. Work at a sustainable pace
  4. Develop miniminal software i. Produce minimal functionality ii. Produce only the code requested iii. Develop only code and tests
  5. Accept change
  6. Develop iteratively i. Produce frequent working interactions ii. Freeze requirements during iterations
  7. Treat tests as a key resource i. Do not start any new development until all tests are passed. ii. Test first
  8. Express requirements through scenarios

Back to basics

Dave Thomas finishes his blog post by showing us how to do something in an agile fashion:

  1. Find out where you are.
  2. Take a small step towards your goal.
  3. Adjust your understanding based on what you learned.
  4. Repeat.

And “when faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”

That’s it.

Orientate, plan, do, check, adjust, repeat.

Where do we need to focus?

I’ve often found these lists of principles useful to focus the mind on what’s important about working with agility.

Which principles stand out as those we need to focus on

  • as a company?
  • as a team?
  • as an individual?

What is the next small step we need to take?

Originally posted on Vision internal blog.

Team meeting via Google Hangouts

Daily meeting via Google Hangouts
Daily meeting via Google Hangouts

Last week I had to work from home one morning. Our team meets at 09:30 every morning to catch-up. Years ago I suppose I would have had to either phone in or miss it.

We used Google Hangouts to allow my colleague Lewis and I to take part, connecting remotely.

Isn’t the world wide web an amazing thing!

Agile planning poker

For a few months we’ve been starting to use Agile, and specifically Scrum, methods in planning and managing our Web projects at work.

This week we adopted a new practice: planning poker.

Agile / Scrum iteration planning board
Agile / Scrum iteration planning board

Like many teams starting out with Agile practices we didn’t just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:

The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.

Continue reading Agile planning poker