Value driven planning – Sprint Planning

The basic idea of Sprint Planning is for the team to negotiate the scope for the sprint with the Product Owner in a limited amount of time (time box).

The Sprint Planning ceremony needs to be organised and facilitated by the Scrum Master, however, the Product Owner needs to produce the agenda (Product Backlog) for the ceremony.

The Product Owner needs functionality to be implemented and to spend development money wisely. The team wants to select a mandate they can fulfil at the end of the sprint.

This is called a Sprint Contract between the Product Owner and the team.

The purpose of Sprint Planning is for the Product Owner and the team to negotiate what should be accomplished during the sprint (Sprint Contract)

—————————————–

Sprint Contract: It is simply an agreement between the Product Owner, who agrees not to change his mandate before the end of the sprint, and the team, who commits to delivering a defined set of functionality by that time.

—————————————–

Meeting Parameters:

Scrum Master facilitates the ceremony; however, the Product Owner brings the agenda.

Before the start of Sprint Planning, the team had to have seen, understood and estimated the stories, otherwise the ceremony will drag on and a productive Sprint Contract which needs to produce a product increment to support the financial investment will not be reached.

It’s important that the stories produced by the Product Owner needs to be small enough to be delivered in one sprint and well defined acceptance criteria ( conditions of satisfaction ) will increase the team’s ability to deliver the planned product increment at the quality level expected by the Product Owner.

It is important for the team to understand their capacity upfront in order to gauge the amount of work they are willing to accept into the Sprint Contract.

That will also enable the team to negotiate buffer stories with the Product Owner as part of the Sprint Contract, however, only to be done if the team has completed ALL the stories to completion as set out in the Sprint Contract. Buffer stories will enable the team to take on more work may they finish the Sprint Contract before the end of the sprint, therefore, increasing the sprint velocity and assisting the Product Owner to produce higher return on investment for the sprint.

It’s important to note that Sprint Planning in total needs to take no longer that one working day. Sprint Planning 1 – Backlog Analysis Workshop (4 hours), and Sprint Planning 2 – Selected Backlog Design and Task break-down (4 hours).

Sprint Planning in practice

Preparation:

The Scrum Master has the following preparation duties:

•  
  • Prepare the team room/space with all the necessary equipment the team and Product Owner would need to effectively communicate and plan (flip charts, whiteboard, pens, paper, projectors, laptop, sticky notes, printed stories etc)
  • Prepare the team capacity and help the team understand their own capacity for the sprint (find out who’s on leave etc beforehand)
  • Ensure and assist the Product Owner to produce a well-defined, estimated and prioritised Product Backlog at least a day before Sprint Planning to the team so the team can be well prepared.
  • Collate and prepare the output from the previous Sprint Review and Retrospective.

The Product Owner has the following preparation duties:

•  
  • The Product Owner needs to, with the assistance of the Scrum Master, ensure that the Product Backlog is understood and estimated by the team.
  • The Product Owner needs to ensure the team receives the prioritised Product Backlog in-time to be well prepared for the Sprint Planning sessions.
  • The Product Owner needs to ensure that all stories within the Product Backlog has well-defined acceptance criteria (conditions of satisfaction) attached to them in order to assist the team in gauging the scope and desired outcome of each backlog item.

The team has the following responsibilities:

•  
  • Assist the Product Owner in estimating the Product Backlog before the Sprint Planning sessions.
  • Prepare themselves on the Product Backlog produced by the Product Owner before the start of the Sprint Planning sessions

Moderation:

Scrum Master kicks off the ceremony by ensuring that

•  
  • The team understands their capacity for the sprint
  • The team understands and have access to the previous sprint’s review and retrospective items
  • The team understands and if necessary enhance the Definition of Done (DoD) for the sprint

The Product Owner will then inform the team of the release vision and the planned sprint goal and communicate with the team in finalising the Sprint Goal.

The Product Owner will then present the Product Backlog to the team whereby the team will start to analyse the Product Backlog from the top by…

1. Starting with the first item on the backlog understand the requirements of that backlog item (use your flipcharts)

2. Understand the acceptance criteria (conditions of satisfaction) for that backlog item

3. Once the team has a clear picture of what needs to be achieved to complete that item, they either accept or decline that item into their sprint.

4. Then start again from point 1 until the team feels that they have reached their sprint acceptance saturation point

———————————————————

Note: Ensure that your team does not accept items into the sprint based on the estimates of each item making up the sprint velocity, nothing is more wrong – ensure that your team accept items based on the understanding of what needs to be done and willingness to complete that item within the sprint

———————————————————

It’s important that the Scrum Master facilitates the whole process and ensure that the team are tracking well in the time allotted.

It’s also very important that the Scrum Master does ask the team at some stage a very important question on the items they have already selected from the top. Are they still comfortable with what they selected and that they will be able to deliver to complete satisfaction at the end of the sprint?

At the end of your first Sprint Planning session after the team has selected their items to be included into the sprint, send the Product Owner away and then repeat the question above to the team again, however, this time more serious!

Once the team has answered and made their commitment to deliver the selected items to full completion at the end of the sprint, then communicate the final selected list of items to the Product Owner, but be aware, this is not open for discussion anymore. (This helps teams to avoid being pushed into delivering more than they know they can commit to)

At this stage teak a break and then bring only the team back to the room where they need to decompose the selected items into tasks. The Product Owner is not part of this session as the team needs to candidly discuss and decompose the items, however, the Product Owner needs to be ‘on-call’ to provide clarification or renegotiations on items as they are decomposed. Once the team has decomposed all the items, your team will then have a Sprint Backlog and work can immediately commence.

Regards

Arrie van der Dussen

Agile Business Manager / Agile Coach

Kaizania

agile@kaizania.co.za

Daily Stand-up – 3 questions or not?

Over the years using and implementing Scrum in organisations, I struggled sometimes with the value of the daily-standup…

Why did I struggle?

- The teams started off excited and it worked, however, as the adrenalin rush dissappeared, the daily stand-up became a drag, something they had to do with no excitement and not a lot of communication or team co-ordination

- By asking every member to come to the front and answer the 3 questions, there was no cohesive drive towards completing stories from the top ( prioritised ), people were all over the board and it was difficult to see what is what

- The communication as a team was not good, there was no hype, there was no excitement and no drive towards a mutually accountable goal at all…

The Solution

Well, this may go against the books and theory, however, it works for my teams…

I changed to ‘walking the board’, and a lot of Scrum practitioners are now doing the same…

I asked the team to communicate and co-ordinate collectively on each story, one at a time, from the top ( highest priority ) and talk through each story as a team…

The Result

It worked! I managed to solve 2 problems with this…

Problem 1: No effective communication and co-ordination as a team

Problem 2: Working all over the board, instead of delivering stories as a team from the highest priority first!

By walking-the-board we manage to solve both… the teams are now excited, they communication extremely well, the focus together as a team on their mutually accountable goal and the best is that suddenly they are holding each other accountable for that goal…

Since, I have used this regularly when I encounter the above mentioned problems… walking the board provides a Scrum Master or Coach with a method to mature an Agile team very fast…

Please go to http://agile-commentary.blogspot.com/2009/04/walking-board.html for another Agilist who did the same…

Kind regards

Arrie van der Dussen

Agile Business Manager

Kaizania

agile@kaizania.co.za