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

Why commitment is so important

Trial and error has now repeatedly shown that it is not advisable to bend the agile methods.  We have tried and take short cuts, or to make things work specifically for our situation, but time and again we’re brought back to the same principles.

As we know it is very un-scrum to NOT make a commitment during sprint planning – It almost defeats the purpose of scrum.  We’ve been under the impression that our situation is very unique, and have tried come up with solution for our problem areas. The only plausible option seemed to do planning for a certain set of user stories, but not to commit to these.  Instead we gave the client the benefit of being able to add other user stories midway through the sprint, which would have a direct effect on the team’s ability to complete the planned stories. 

The reason for this is that the software being worked on is already in a production environment, which brings up a few maintenance issues every now and then, as well as customer specific change requests.  For this specific project we usually run two week sprints, and if something pops up in the middle of a sprint, it’s just too long for our client to wait until the next sprint.  I’ve heard about the swop out theory, and we have tried it, but this didn’t work well for our  client for various reasons.

To get back to our non-committed sprint, the team obviously didn’t have any objections to this because it meant they didn’t have to take the responsibility, but since our two week sprints are paid for based on the amount of days, and not work done, this really didn’t benefit our client.

Our sprint ended with one planned user story outstanding, but since this wasn’t committed to it was perfectly acceptable to move this story to the next sprint.

This didn’t have any negative implication for the team, however our client didn’t get the functionality he bargained on getting.

During the retrospective we decided, together with the client, that we will not be doing another non-committed sprint. 

This created a false expectation for our client, and when the team couldn’t meet up to it no one could take the responsibility.

The client has agreed to stick to committed sprints only, even though he will have to wait for maintenance and change requests a bit longer, it is definitely worth it. 

This way he will know exactly what functionality to expect at the end of the sprint.  In the event of an urgent maintenance request, the client can then decide whether to cancel the current sprint, or to swop it out with a committed story of equal size, which the team hasn’t started working on yet.

Regards,

Danette Kok

Scrum Master

Kaizania

Bugs – How do we handle them in an Agile context?

How do we handle bugs?

A question I receive a lot when coaching organisations and teams…

Well, I found this blog post which provides a really good explanation of how Agile teams need to look at bugs…

http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/

Arrie van der Dussen

Agile Business Manager

Kaizania

agile@kaizania.co.za

Good Product Owners are too rare

The past few years while using Scrum and helping organisations adopt Agile and Implement Scrum the case for Good Product Owners became clear…

Let’s be honest, it’s not that difficult to implement Scrum within any organisation at all, it’s difficult to bring all that’s needed together for any Scrum implementation to show the expected success organisations so badly wants to see.

One of the key roles to any Agile adoption and Scrum implementation must be a good Product Owner, yet this is where things usually struggle to get forward momentum or sometimes the lack of a good Product Owner make the whole implementation fail. Who’s blamed then, well, most of the time, Scrum!

Why blame Scrum? Scrum is just a process, a framework and a very lightweight framework. That said, the reason, and the only reason why that organisation knew that they were failing was most probably because Scrum showed them that they are running the risk of failing. The only thing that organisation managed to overlooked was what Scrum was trying desperately to tell them, that their role of Product Owner was failing! If only we listen when Scrum speaks to us! Yet, the era of the blame game is not over yet, we have some way to go, we are still searching to feel comfortable and protected by placing blame on process, frameworks etc, instead of having the courage to face up to what is standing in our way of moving forward…

So, that out of the way, let’s look at the role of Product Owner then…

A good Agile Product Owner

·         must be responsible for the success of the project the team delivers.

·         has to make business decisions, about what is important to him and how much it is important in comparison to other requirements he may have.

·         must provides the vision about the product for the team.

·         provides the team with user stories and needs deep domain knowledge to do that.

·         has prime responsibility to validate the deliverables the team produces. Do they meet his quality requirements? Are all conditions of satisfaction met?

·         has to provide timely feedback to the development team, when questions arise.

·         has to be able to make decisions on the spot, to resolve questions on how to proceed.

·         needs to be in constant communication with the team and other stakeholder or project sponsors

·         has to keep the financial situation of the project under close scrutiny

Author: Jiri Lundak

Being able to do all the above, a good Agile Product Owner must surely have the following skills and attributes then…

·         the ability to communicate effectively on all levels

·         good business sense

·         technical foundation and

·         trust

Given this, does your Product Owner fulfil these criteria or is it that organisations don’t have the courage to get the right person to fulfil this role, do they just take traditional roles to fulfil this crucial role without realising the consequence?

Agile adoption and specifically Scrum implementations lack the forward momentum expected or fail most of the time because of the lack of a Good Agile Product Owner, not because Agile or Scrum or Lean or XP. Those are just processes and frameworks, it’s still the quality of person and teams making the world go round!

Work hard at your Product Owner role and your road to Agile success will be much easier! Your Product Owner must be by far the most important person for any Agile team!

For Agile Product Owner training, please visit the Kaizania Agile Training section…

Arrie van der Dussen

Agile Business Manager

Kaizania

Agile Product Owner Course

Do you want to deliver the right product at the right time at the right price?

Do you have the ability to deliver customer value while dealing with inherent project unpredictability?

Would you like to balance stability with flexibility, order with chaos, planning with execution, optimization with exploration and control with speed?

This course will show you how…

Download the course brochure here… for bookings or more information, please contact us at agile@kaizania.co.za or phone us direct on +2783 700 2181 

Arrie van der Dussen

Agile Business Manager

Kaizania