“The team starts to assemble in the meeting room.  Pam starts “Sorry guys, I’ve been really busy this week and not really had a chance to look at the backlog.” There is an audible sigh from the room. Pan continues, “Let’s start with 23439”

I find reading about situations helpful. Hence with the different areas of Scrum I have included the appropriate definition from the scrum guide and a  series of cases studies. These small story snippets start poorly and improve with each subsequent case. These cases highlight common failures of Scrum, which after reading these I would like to think you could avoid them, or at least recognize them and see a possible way forward.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Topic Two: how will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Case 1: The too busy product owner

The team starts to assemble in the meeting room.  Pam starts “Sorry guys, I’ve been really busy this week and not really had a chance to look at the backlog.” There is an audible sigh from the room. Pan continues, “Let’s start with 23439. Hmm this description is not right, Paul pass me the keyboard and I will correct it.” 10 minutes has passed and Paul the Scrum Master interrupts the process. “Let’s stop a second should we just concentrate on the items that have been through refinement.” Pam is a bit miffed “We are looking at 23439, stop interrupting and will we get it done quicker”, Paul continues “We did agree to a time limit per story, how does the rest of the team feel.” Tony rolls his eyes, Dale says “Just get on with it”.

Alan stands up to get a cup of coffee. After a further 50 minutes and after much discussion questions still need answering. Pan concludes,” well better stop for lunch and carry on this afternoon.

In the afternoon the team gets together. Paul starts “OK, let’s bring in stories”. Pam pipes up “Oh, done that already, take a look”. Paul is taken aback, “You cannot just bring in work that, it is for the team to decide”, and Pam retorts “Well, they would select these items any way. I did make sure not to go over too much of our average velocity.” Paul looking at the board, “That is 40% more than we normally do, how does the team feel about that?” The team shrugs. Pam continues, “Should be fine the guys are usually not rushed off their feet.”

Case 1 Notes:

Points to think about:

  • Do you feel the team have a clear goal to achieve for the upcoming sprint?
  • How do you think the team feels like when work is presented in this manner?
  • What was the Product Owner thinking when selecting the work to be done in the sprint, how would that be reflected by the team?
  • What would be the effect of having too much in the sprint?

My thoughts

The product backlog is one of the key scrum artefacts, it is really important that it is looked after and constantly worked on. This is a deep failing of the Product Owner and should focus more needs of the team and the product.

A key ingredient of a sprint is the Sprint Goal; this informs the team of the overarching point to the sprint and how to measure success.  If the goal is missing as it was in this instance then the outcome is unclear and we are just focusing on the output.

The Velocity in story points indicates the amount of work the team can achieve. This value will generally fluctuate; often the average velocity is used to help plan future work. This is called Yesterdays Weather Forecast. Velocity is calculated by adding up all the stories points of all the stories that were completed (Done) during the sprint. Story points are a method to determine relative size of work. This is used instead of hours.

Getting the Product Owner to select the work for the team sounds on the face of it fine; it’s not. Another artefact is the sprint backlog belongs to the development team. They select what goes in it, not the Product Owner. This is key, a Project Manager would tell the team do this work we need it and work as hard as you can. Over time the team would get tried and get fed up working all hours, so quality will suck. Team members leave and have to be replaced quickly with contractors. The Product Owner by placing items into the sprint backlog is acting like a Project Manager, telling the team. The team not wanting to upset the manager just accepts what they have put in, regardless that it is more work than normal. Effective work time on Sprint Backlog items is usually around 60-70% of the total work time  the other 30-40% will be taken up by breaks, Emails, Slack, Skype, helping others, build merges, technical debt, backlog refinement and other team oriented learning sessions.  By maxing out the team the likely outcome is incomplete stories sprint after sprint.  A good analogy is to think how effective your computer operates when it is running at 100%.

The Product Owner’s approach should be to ask the team, what can we take in? Then you may find out that Tony is out for two days and Dale wants to bring in some technical debt that will help out development in the up and coming sprints. This approach feels much more conversational and collaborative. Teams that finish early accelerate faster.

It is generally a good idea to keep the backlog in good shape, so planning is not such a chore. To help, the team will have a refinement meeting during a sprint, this is where stories are reviewed, broken down further and questions raised. These meetings can take a while so there are options to how these are run:

  • Do not plan these, just have them when needed.
  • Have short meetings that last 20, 30 minutes at peoples desks, just focusing on a particular area. This can be help, so not everyone need attend, the flow of meeting can work better with fewer attendees.
  • If only a few people attend at a time, make sure everyone has attended a refinement meeting sometime during a sprint.
  • Have them 15 minutes each day, may be looking at 1 or 2 stories at a time.
  • Workshops, once a month to plan the next few sprints.
  • Print out the story cards and go to the coffee shop for an informal discussion.

There are many approaches to backlog refinement, how it happens it is up to you. Do not get stuck in the mind-set that it has to be a meeting in a meeting room in front of a PC. It should be a team effort to create the backlog, don’t make the Product Owner a Jira / TFS monkey.

Case 2: Dynamic Plaining

The team meet in the Scrum Area, they are standing, sitting around the project table . Pam Starts “Hi guys we want to look at purchasing this sprint, our user is Joe, he works in the purchasing department. Please say hi to Joe.” Pam motions towards Joe. Joe say “Hi all, looking forward to working with you all.” Pam continues,” Joe will help us with the acceptance testing, I have cleared it with his manager. So, the goal for this sprint is such: Joe wants to be able to purchase directly from 3rd parties. In this instance he wants to buy pre-configured PCs directly from Dell from within our system, saving 50% time and 25% money”.

Dale thinks about this a minute “Do we know what other 3rd parties we would have to work with?” Pam responds “Not at the moment, we should not over engineer it as the direction may be determined by the 3rd parties we choose. “ The team bring in 5 stories that are already estimated that make up this feature, noting that Tony is out for two days and Dale wants to bring in some technical debt. Within 20 minutes the meeting is complete, the amount of work selected is comfortably 60% of the total work time, including the fact the Tony is away.

In the afternoon the development team assemble by the team area and start breaking down the stories into tasks, drawing some designs on the white board, Brent takes photos of the designs and adds them to the team’s wiki page. The tasks are added to the sprint backlog board, they do not bother adding tasks to the electronic system as these are just for the developers. The story progress informs the Product Owner and Scrum Master with the granularity needed.

Case 2 Notes:

Points to think about:

  • Do you feel the team have a clear goal to achieve for the upcoming sprint?
  • How do you think the team feels like when work is presented in this manner?
  • Do you feel the team would be bored in the planning meeting?

My thoughts

Having a clear goal and making that goal a story with a real user and including the impact that will have on the business makes the outcome real. Often, development teams do not understand how their work will affect the bottom line of the company or whom it will impact or why.  Equally having a conversation and agreeing as a team of what to bring in, means the team are more likely to buy into what they are forecasting to achieve.