GROW Your Retrospectives


I have been assigned as the PO to a non-development scrum team for product marketing. After one week of work, we have delivered only 2 banner ads from a team of 10 people. The problem seems to be the process of approvals, reviews, kickoffs, briefs, tickets etc that need to happen in order to deliver the work. How would you coach me to help everyone see that our current process could be improved?


Chris Sims with a plant.My first recommendation is to address this in the team’s retrospective. As product owner, it’s appropriate for you to say you would like to see the team get more ads, or other product backlog items, done in a sprint. Be a bit careful though; it’s very easy for the team to hear that as you blaming them or thinking that they’re not working hard. From the tone of your question, I don’t think that’s where you are coming from, but still be aware they may interpret things that way.

In the retrospective, you might consider using the GROW model that I’ve been writing about recently. GROW is designed for coaching, but it’s also great for structuring a retrospective. It stands for: Goal, Reality, Options (and Obstacles), and Way Forward. It’s an arc that you, or the scrum master, might guide the team through.

Start by identifying a goal that the whole team can get behind. Perhaps it’s something like: We will get two more ads delivered in the next sprint, compared to last sprint.

This is where the team establishes a deeper shared understanding of what is currently happening and why. Perhaps guide the team through a process mapping exercise, to identify all the steps and tasks that were required to get the stories delivered.

Once everybody has a good understanding of the current reality, then you can move on to identifying options to speed this up. Brainstorm ways to shortcut some of the bureaucracy. In this phase, you really want to be open to any ideas. Don’t do any critical thinking; just collect the ideas.

Identify the current obstacles as well as obstacles that might get in the way of some of the ideas just generated. This gets a little iterative, back and forth between options and obstacles.

Way Forward (Will)
Ultimately, you want the team to identify their way forward. What is it they will try in the upcoming sprint? Think of it as an improvement experiment.

I like that tools like GROW often have multiple applications. It’s a coaching tool! It’s a retrospective tool! It’s a floor wax! It’s a dessert topping!



Posted in agile, coaching, scrum | Leave a comment

Coaching Questions With GROW

Chris Sims with a plant.My previous article covered the GROW coaching model. This article builds on that by adding coaching questions. Questions are a powerful tool a coach uses to help the client find their own way forward. While the coach can provide information and guidance, a key element of coaching is supporting the client in solving their own problem.

Some questions help the client see things in a new way, or consider things they hadn’t before. Much of coaching is deep listening. Questions are the invitations we give to our clients, asking them to share with us. They also allow the coach to gently guide the client’s examination of the situation, and ultimately move them into problem solving and action planning.

Here is a list of coaching questions that you might use in each of the stages of the GROW coaching framework. This isn’t a script! It’s more like a menu. You guide your client through the stages of the GROW model by choosing questions from this list.

(G) Goal Setting

If you could do anything you wanted, what would it be?
What is the desired outcome?
What exactly do you want to accomplish?
What do you want?
What do you really want?
How do you want it to be?
What would that look like?
How will you know you have reached it?
How will you know when the objective is accomplished?
When do you expect to see the outcomes?

(R) Understanding Current Reality

What do you make of it?
What is your assessment?
What do you know about it now?
What kind of picture do you have right now?
How would you describe this?
How would you boil it down to the real essence?
How would you summarize it?
What caused it?
What’s behind it?
What are the other angles?
What part of this have you not yet explored?
What is the bigger picture?
What parts can you control?

(O) Options

What are your options?
How could it be improved?
How do you suppose you could improve the situation?
What are the possibilities?
What are possible solutions?
Is there a ‘win-win’ possible?
What other options are there?
Is there another possibility?
How else could this be handled?
How many options can you think of?
What resources are available to you now?
What would make it possible?
Who could help?
Who could you ask about it?
How can you work around that?

(O) Obstacles

What seems to be the main obstacle?
What is the big challenge here?
What are the chances of success?
What is stopping you?
What is holding you back?
What concerns you the most about it?
What is the cost of that?

(W) Way Forward / Will

What will you do?
Where do you go from here?
What kind of plan do you need to create?
What is the action plan?
What is your game plan?
What do you plan to do about it?
Now what?
Is this the time for action?
What action will you take?
What is your first step?
What are your next steps?
When will you do it?


Using questions to help someone find their own answers is a skill that takes time and practice to master. Find someone, perhaps another aspiring coach, to practice with. Here are instructions to guide you through a practice session.

Further Reading

If you haven’t already, go back and read GROW coaching model.
Here are some sources where you can learn more about coaching questions for use with GROW.

Posted in coaching | Leave a comment

GROW Coaching Model

Agile coaches often encounter clients that are stuck. They know what they are doing isn’t working, yet they can’t find their way out of the dysfunctional cycle. At least, not alone. The coach’s job is to help their client:

  • gain deeper understanding of their situation
  • create a vision for a better future
  • identify obstacles & options
  • create an action plan

Chris Sims with a plant. GROW is a framework that a coach uses to guide their client through this process. The client might be an individual, team, or even a whole organization. GROW is an acronym for the stages of the coaching process: goal, reality, obstacles (and options), and the way forward (will do). Let’s walk through the stages of the model, in the context of Scrum.

The Problem

Carly has been brought in as a Scrum coach to help a stuck team. This team frequently fails to deliver the forecasted product backlog items from sprint planning, and rarely achieves their sprint goal. Despite working harder and harder, the team keeps repeating this pattern. The team and the stakeholders are unhappy.


As a coach, you’ll want to help your client create a goal that is inspiring, challenging, and SMART. This is often an iterative process, with the goal being revised as you guide the client through the other GROW steps.

Carly talks to the whole team, including the product owner, asking how they would like things to be in the future. What future reality do they want to create? The product owner wants the team to regularly achieve their sprint goals, and to deliver the stories that they pulled in during sprint planning. The whole team wants to stop looking foolish in front of the stakeholders, without constantly making excuses for why they didn’t deliver. Carly guides them as they craft the following goal statement:
“Achieve our sprint goal at least 75% of the time, without overtime.”


Before the client can make a plan to achieve their goal, they need to clearly see their current situation. Frequently, people jump to problem solving without fully knowing their starting point. Often they are missing information they need to solve their problem. In fact, this lack of understanding is frequently what has kept them stuck.

Now that the team has a goal, Carly helps them assess their current situation. They already know the surface issues: they are working long hours and not delivering on their commitments. Carly asks how they decide what product backlog items (stories) to commit to in sprint planning. The team shares that they are estimating the hours for each story during sprint planning, and then committing to stories based on their available time to work. Further discussions with the team bring to light that most stories take longer than expected and unplanned work often gets brought in during the sprint as well.


In this phase of GROW, the coach helps the client identify options. Often you will start by brainstorming. More options is better. Don’t worry too much about how good the ideas are. Once a number of options have been identified, then the critical thinking can begin to select the best ones.

Carly helps the team identify a list of possible things to try, as improvements. Carly offers some suggestions, and supports the team as they come up with their own ideas. Some of the options identified are:

  • Start holding a product backlog refinement meeting each week to better understand and estimate items in the product backlog, before sprint planning.
  • Switch from hours to story point estimates, and then track how many points are associated with the completed stories each sprint (velocity).
  • Use yesterday’s weather, an approach where the team commits to no more than they actually got done in the previous sprint.
  • Refuse to accept any new work during the sprint.
  • Hire more developers for the team.


Not all descriptions of the GROW model include this part, but I find it helpful. There are obstacles, both known and potential, that may block the path to success. The coach helps the client identify obstacles that are already in the way, as well as those that might arise as the client pursues the ideas generated in the previous step. Often options and obstacles for a bit of an iterative loop, where options have obstacles and obstacles have options.

Carly next asks the team to identify what could go wrong. What issues might make some of these options difficult? The team identifies some possible obstacles:

  • Taking time for a backlog refinement meeting will be difficult to justify, given that they are already behind. Managers will likely want them to stay ‘heads down’ building stuff.
  • They haven’t used story points for estimating before, and they don’t see how that approach would be as accurate as hour estimates.
  • The product owner is uncomfortable with the idea of the team only committing to the amount of work they completed in the previous sprint, because the stakeholders are putting pressure on the product owner to deliver more.
  • None of the team members really believe that they really can tell managers and other important business stakeholders that they won’t accept new work once the sprint starts.
  • Hiring people takes time. It also requires budget approval, which is difficult to get.

The team explores these obstacles and tries to find counter-measures to overcome them. For example, Carly tells the team about the emergency protocol for dealing with unplanned work. She also offers to teach the team how to use the Team Estimation Game, to create story point estimates.

Way Forward

This phase is sometimes called will, as in what will the client do now? This is an action planning step. The coach supports the client as the client creates their plan. Statements that start with “I will…” or “We will…” are a good way to capture the action plan. A key part of this is identifying how the client will be accountable for implementing their own plan. Sometimes the coach supports the client with mutually agreed accountability check-ins.

Before the team can get lost in analysis paralysis, Carly helps them identify an option that they are ready to try. From there, she facilitates them as they create a plan to try the new approach.

The team decides to try yesterday’s weather to help them make more realistic commitments. They aren’t ready to make the move to story points, so they will use their hour estimates for now. At the end of each sprint, they will check the original estimate for each story that was completed, and total up those hours. In the following sprint, they will commit to no more than that many hours of estimated work.

Carly has the team revisit their goal statement:
“Achieve our sprint goal at least 75% of the time, without overtime.”

She asks them to revise it to be more specific and to make sure they believe they can achieve it. The team adjusts the wording slightly to:
“Achieve our sprint goal in at least 3 out of the next four sprints, with less than half the overtime we’ve been putting in.”

The team agrees to try this for four sprints. After that, they will revisit the topic in a retrospective and decide if they want to modify their approach.

Example Coaching Session

Here’s an example coaching session from South West Coaching Ltd.

Further Reading

This article is the first of two. The next one is Coaching Questions With GROW.
Here are some sources where you can learn more about the GROW model.

Posted in agile, coaching, scrum | Leave a comment

Online Office Hours With Chris, And More!

Chris Sims Office HoursThe COVID-19 situation has brought many changes and challenges. Every change creates new possibilities for something good. For Agile Learning Labs, it gives us the opportunity to connect with our community in new ways.

Online Meetups

We are moving our MeetUp group online. The Scrum Professionals MeetUp group is going to resume our regular schedule starting this month. Tune in every third Wednesday of the month for a talk or workshop, as well as facilitated open discussion. We will continue having time for job seekers and companies to connect.

Online Office Hours

Every Monday afternoon, you are invited to join me for my open office hour: 3:00 PM – 4:00 PM PDT. This is your chance to ask me anything, and get free advice and coaching. I’m planning to use a Lean Coffee approach to structure each office hour, so the most important and popular topics get the most attention. Each office hour will be listed as a free event in the Scrum Professionals MeetUp group.

If you are not already a member of the Scrum Professionals MeetUp group, join now. It’s free, and so are the events. Each event is a chance to learn, connect, and earn SEUs to help you renew your Scrum Alliance certifications.

Wishing you health, safety and silver linings,

Chris Sims

Posted in agile, coaching, events | Leave a comment

An Abridged History Of Scrum

Old Scrum DiagramI spend my working days helping companies effectively use Scrum and other agile practices to create healthier working environments and increased business value. Today, I found myself reflecting on the path that led here. Below is an abbreviated timeline of events in the evolution of Scrum. I’ve included a few bits of my journey with Scrum as well.

An Abridged History Of Scrum

Winston Royce publishes “Managing The Development Of Large Software Systems.” This paper is often cited as the origin of waterfall development. While Royce describes what became known as waterfall, he argues against it in the paper. He actually advocates for a more iterative, two pass approach, instead of the single pass of waterfall.

Barry Boehm publishes the first version of “A Spiral Model of Software Development and Enhancement.” The Spiral model is iterative, though not necessarily incremental. It has a strong focus on risk reduction.

The Harvard Business Review publishes “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka. They advocate for an approach to product development that would increase speed and flexibility, based on case studies. They describe cross-functional teams working like a scrum in rugby.

The first OOPSLA conference is held. The OOPSLA community includes many of the people who become pioneers in the agile space.

The book Rapid Application Development is published by James Martin. Rapid Application Development emphasizes the importance of adaptation over advanced planning.

Jeff Sutherland, John Scumniotales, and Jeff McKenna create Scrum and use it for the first time at Easel Corporation.

The DSDM Consortium is founded and the first version of the Dynamic Systems Development Method (DSDM) is published. DSDM fixes cost, quality and time. Scope is variable and prioritization is a key aspect of DSDM. DSDM is both iterative and incremental.

The first wiki, WikiWikiWeb is created by Ward Cunningham. Many agile pioneers use it to discuss and debate the various lightweight methodologies they are creating.

Even before this, many pioneers were actively discussing and debating their ideas on the usenet newsgroups, including comp.lang.smalltalk (many agile pioneers were part of the Smalltalk community) and comp.object. In 1995 Jeff Sutherland starts a thread titled “SCRUM and Why the Waterfall Methodology is a Fool’s Errand …,” in which 60 authors discuss and debate various practices that would eventually be called agile practices. An unedited archive of some posts from those groups is available here.

Jim Coplien publishes Pattern Languages of Program Design.

Kent Beck becomes the project leader of the Chrysler Comprehensive Compensation (C3) system. Kent, Ron Jeffries, Ward Cunningham, and Martin Fowler create Extreme Programming (XP) while working on C3.

Ken Schwaber publishes “SCRUM Development Process” which describes scrum and emphasizes the importance of an empirical approach to software development.

Jeff De Luca creates Feature Driven Development, while working on a project for a large Singapore bank. This incremental approach builds one feature at a time.

Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, and Jeff Sutherland publish “SCRUM: An extension pattern language for hyperproductive software development.”

The book Extreme Programming Explained by Kent Beck is published. When the second edition comes out in 2004, Cynthia Andres joins Kent as author.

Alistair Cockburn shares early descriptions of the Crystal Clear methodology on the WikiWikiWeb.

Feature Driven Development is described in Chapter 6 of the book Java Modeling in Color with UML.

The book Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Jim Highsmith is published.

Ron Jeffries, Ann Anderson, and Chet Hendrickson publish Extreme Programming Installed.

Chris Sims initiates the use of Extreme Programming at FactSet.

The Manifesto for Agile Software Development is created at a 3 day event at The Lodge at Snowbird ski resort outside of Salt Lake City. The word ‘agile’ is chosen over ‘lightweight’ to describe the approaches practiced by the participants.

Agile Alliance forms.

The book Agile Software Development with Scrum by Ken Schwaber and Mike Beedle is published.

Chris Sims and his team release first version of FactSet’s APW product built using Extreme Programming.

The Scrum Alliance is formed by Ken Schwaber, Mike Cohn, and Esther Derby.

Lean software development movement gains momentum when Mary and Tom Poppendieck publish the book Lean Software Development: An Agile Toolkit.

First Scrum Gathering held in Boulder, Colorado.
First European Scrum Gathering held in Vienna.

Alistair Cockburn publishes Crystal Clear: A Human-Powered Methodology for Small Teams.

Jeff Sutherland publishes the paper “Agile Development:
Lessons Learned From The First Scrum

The Boston Scrum Gathering happens.

Spring Scrum Gathering held in Portland, Oregon May 7-11.
Fall Scrum Gathering held in London, Nov 12-16.

Chris Sims starts Agile Learning Labs and presents agile sessions at Silicon Valley Code Camp.

Chris Sims among others, present sessions at the Chicago Scrum Gathering.

Agile Learning Labs offers their first public workshops.

A pre-release proof of Scrum Guide is distributed at the 2009 Scrum Gathering in Orlando. Chris Sims and Ainsley Nies facilitate the Open Space at this gathering. The proceedings are still available.

The first official version of Scrum Guide is published by Scrum Alliance.

Chris Sims and Jeff McKenna teach Certified Scrum Master workshops together.

David Anderson publishes Kanban: Successful Evolutionary Change for Your Technology Business.

The Scrum Guide is updated in July.
The Scrum Guide is updated again in October.

Chris Sims and Hillary Louise Johnson publish The Elements Of Scrum.

Chris Sims and Hillary Louise Johnson publish Scrum: a Breathtakingly Brief and Agile Introduction.

The Scrum Guide is updated.

The Scrum Guide is updated.

The Scrum Guide is updated. A partial history of revisions to the Scrum Guide is published.

Further Reading

Jeff Sutherland’s Origins of Scrum.


It’s been a fascinating journey. Those of us practicing Scrum today stand on the shoulders of the giants who blazed the trail to now. I’m sure I’ve left out important events and people. Despite best efforts, I may have dates or other details incorrect. Please fill in the missing bits by leaving comments or sending me a message.



Posted in agile, scrum | Leave a comment

Agile Conference List 2020

Graduates of our workshops often ask how they can continue their journey of learning about scrum, and earn some Scrum Educational Units (SEUs). Attending conferences is a great way to accomplish these goals. Here is a list of conferences that you might consider attending in 2020. I’m sure we’ve missed some good ones, so point those out to us by leaving a comment.

Event Start Date Location Focus
Agile Open Northwest February 3 Seattle, WA Open Space
Open Leadership Symposium February 4 Tampa, FL Organizational Change
European Testing Conference February 6 Valencia, Spain Software Testing
Agile For Automotive Silicon Valley February 26 Silicon Valley, CA Automotive
Product Camp Portland March 7 Portland, OR Product Management
Agile Open San Diego March 11 San Diego, CA Open Space
ProductCamp Silicon Valley Postponed Santa Clara, CA Product Management
ScanAgile April 1 Helsinki, Finland Agile
El Scrum Day Colombia April 3 Medellín, Colombia Scrum
Agile Games Midwest April 25 Virtual Agile Games
Goto Chicago April 27 Chicago, IL Software Development
Agile Austria Conference Postponed Graz, Austria Agile
Deliver Agile Postponed Columbus, OH Agile Engineering Practices
Global Scrum Gathering New York Canceled New York, NY Scrum
Agile Maine Day Canceled Portland, ME Agile
Mile High Agile Canceled Denver, CO Agile & Lean Methods
Agile & Beyond Postponed Detroit, MI Agile
Mob Programming Conference Postponed Boston, MA Mob Programming
Agile Games New England Postponed Boston, MA Agile Games
Agile + DevOps West June 7 Las Vegas, NV Agile
XP 2020 Postponed Copenhagen, Denmark Agile Software Development
Regional Scrum Gathering, Lagos Postponed Lagos, Nigeria Scrum
Regional Scrum Gathering, Hyderabad June 20 Hyderabad, India Scrum
Joy Of Coding Canceled Rotterdam, Netherlands Software Development
Agile Testing Days US June 21 Chicago, IL Agile Testing
Regional Scrum Gathering, Rio de Janerio July 2 Rio de Janerio, Brazil Scrum
Agile On The Beach July 9 Cornwall, England Agile Product Development
ÜberConf July 14 Denver, CO Programming
System Dynamics July 19 Bergen, Norway Systems Dynamics
Agile 2020 July 20 Orlando, FL Agile
Agile Lean Europe August 19 Riga, Latvia Agile
Regional Scrum Gathering, Shanghai August 21 Shanghai, China Scrum
Agile Prague September 14 Prague, Czech Republic Agile
Targeting Quality September 21 Cambridge, Canada Software Quality
eXperience Agile September 26 Lisbon, Portugal Agile
Regional Scrum Gathering Belgrade October 6 Belgrade, Serbia Scrum
Craft October 13 Budapest, Hungary Software Craftsmanship
Global Scrum Gathering Lisbon October 19 Lisbon, Portugal Scrum
Regional Scrum Gathering, Kolkata November 6 Kolkata, India Scrum
Silicon Valley Code Camp November 7 Mountain View, CA Software Development
Agile + DevOps East November 8 Orlando, FL Agile
Regional Scrum Gathering Melbourne December 3 Melbourne, Australia Scrum
Agile Open NoCal TBD SF Bay Area, CA Open Space
Agile Open SoCal TBD Irvine, CA Open Space
AgileDC TBD Washington, DC Agile
Posted in agile, conferences, events | Leave a comment

Daily Scrum

Team holding a daily scrumThe daily scrum is the event where the development team inspects and adapts their work plan in order to make the most progress possible towards their sprint goal each day. It is one of the most misunderstood events in the scrum framework, and often implemented ineffectively. By understanding the purpose of the event, your team can realize much more value from their daily scrum.

Often, the first thing a person learns about scrum is the traditional way to run a daily scrum. They learn the three magic questions: What tasks did I get done yesterday? What tasks will I do today? What impediments am I aware of?

What people often don’t learn is why the team holds a daily scrum. If team members don’t understand the purpose, it’s very easy for the daily scrum to devolve into a meaningless status meeting, where each team member walks away wondering why they just wasted 15 minutes of their day.

The purpose of daily scrum is to allow the development team to self-organize around what work should be done today. Most scrum teams work in the complex domain. This means the team’s understanding of the work emerges and changes every day. New tasks are discovered. Some work takes longer than expected. New problems, or opportunities, emerge. In order to be effective, the team needs to inspect and adapt their work plan every day.

The daily scrum has a time box of 15 minutes. Typically, each team member shares what work they completed yesterday, and what work they believe they should contribute today. If there are any problems (impediments), those are brought to light as well. Today’s important work might be removing one of those impediments. Once every team member has shared what they believe they should contribute today, the entire team steps back and looks at the list of tasks that haven’t been picked up. They identify any work that is more important than the work currently slated for the day. Then they collectively adjust their work plan for the day, so that by the end of the daily scrum, the team is confident they are addressing the most important issues for the day.

What Else Might Happen At The Daily Scrum?

Many teams use the daily scrum as their opportunity to decide if a product backlog item(story) is done or not. This makes sense because in the daily scrum, the team is focused on the work, often called tasks or sub-tasks. If there is a product backlog item that has no remaining tasks, then implicitly the development team believes they are done. For an item to be considered done, we really want the entire team to agree. In this way, each member of the team contributes to the decision and is accountable. We want the whole team to own the done decision.

Some teams take a daily confidence vote at their daily scrum. How confident are we that we will achieve our sprint goal? How confident are we that we will complete all the product backlog items that we had committed to this sprint? A common technique for taking that poll is a fist-to-five survey.

Adding or removing product backlog items from the sprint could happen as well during the daily scrum. We do not want the business or the product owner to push scope change onto the team, but it’s perfectly acceptable for the team to pull a scope change from the product owner. For example, if it’s now clear the team will not be able to complete all the stories they originally committed to, it’s a good idea to ask the product owner which product backlog item they would like to sacrifice. The development team can refocus their efforts on the remaining items, thus increasing the chances that those will get done. Similarly, the team might realize they will complete the last of their committed product backlog items today, and there is time left in the sprint. They would ask to the product owner what they should start on next.


At the daily scrum, the development team will inspect and adapt for the sake of the sprint. They will adjust what work is to be done, and by whom, in order to have the best possible outcome this sprint. It supports self-organization, team ownership and accountability for delivering on their sprint goal.

Further Reading



Posted in agile, scrum, teams | 1 Comment

Don’t Change Estimates During Sprint Planning

Team estimating user storiesI encounter scrum teams changing, or worse, creating, story estimates during their sprint planning meeting. This slows down the meeting and it undermines the whole purpose of estimation: predictability.

Predictability is knowing what the business will get and when. Stakeholders might ask the team: “Can we get these features by the end of the year?” Or: “When will the new feature set be ready?”

In a sprint planning meeting, the only predictability needed is a simple yes or no. Is the story (product backlog item) in the sprint? If it’s in, then the stakeholders can expect to get it by the end of the sprint.

The purpose of estimates is to support longer-term predictability, meaning when are we going to get stories from the product backlog? This leads to the reason why we should not change estimates in sprint planning.

When we bring a story into sprint planning and break it down into tasks, we very often will discover things about that product backlog item we didn’t – and couldn’t – know before. Frequently, a team will think oh, our estimate was wrong. We should adjust it. In fact, adjusting the estimate at this time will lead to diminished predictability.

Here’s why. Breaking the story into tasks is something that has us working with the story at a level of detail greater than we have before. If we change the estimate based on what we learn by doing this work, then the estimate becomes a “corrected estimate.” All of the stories in our product backlog will have uncorrected estimates because we have not worked on those yet. If our velocity is based on “corrected estimates,” that velocity will not give a good predictability for a product backlog filled with uncorrected estimates.

Scrum teams typically work in the complex domain, which means there are always unknown unknowns. We can’t expect perfect predictability for each story, but we can achieve good predictability over time. Simply record the points for each story when the story is complete. The team’s burn up chart will fluctuate up and down, but the average rate of delivery (velocity) will give good predictability for when our stakeholders will get their stuff.



Posted in agile, scrum | 4 Comments

Sprint Planning

Scrum team planning a sprint.Sprint planning is the very cleverly named event (meeting) where the whole scrum team creates their plan for the sprint. The outputs from sprint planning are: the sprint goal, the forecast of which product backlog items will be delivered, and the team’s work plan.

Timing Of Sprint Planning

Sprint planning is held at the very beginning of the sprint. The time box for this meeting is two hours for a one week sprint. The Scrum Guide says the time box is eight hours for a four week sprint, though I would hope your team is not considering four week sprints. Remember, a time box is simply a limit. The meeting should never be longer than that. Ideally, you should be able to achieve the goal of sprint planning in less time than two hours if you’re doing a one week sprint.

Sprint Forecast

A goal of sprint planning is to identify a set of product backlog items that the entire scrum team has full confidence that they can deliver to the business by the end of this sprint. Each of these product backlog items is valuable to stakeholders. This list of deliverables will be shared with the stakeholders and referred to as the sprint forecast. It is the set of product backlog items that the team is predicting they will deliver to the business by the end of the sprint.

Sprint Goal

The product backlog items in the sprint should support the achievement of an overarching sprint goal. For example, if we’re a consumer website, we might have a sprint goal of streamlining the checkout process for our customers. We might have several product backlog items, each a specific enhancement to help improve or streamline the checkout process. Each has a specific deliverable that adds meaningful value on its own. Together, they support the sprint goal of streamlining the checkout process.

The sprint goal is a really powerful concept because a well-crafted sprint goal is more important than the individual product backlog items that compose it. Over the course of the sprint, if the team identifies better ways to achieve the sprint goal, it might be reasonable for them to pursue those. They may even shift or change which specific product backlog items they deliver if by doing so they can do a better job of achieving the sprint goal.

Work Plan

The outcome of the sprint from the business’s point of view is the sprint goal and the individual product backlog items that compose the sprint goal. From the point of view of the scrum team, however, there is one more very important component in the output of a sprint planning meeting: The team’s plan for what work they will do in order to achieve the sprint goal. Usually this plan is a big list of tasks. It’s worth mentioning that some tools call these sub-tasks, but I just call them tasks.

A task is an item of work, something that someone or perhaps a pair or even a whole group of people will do. For example: writing some code or doing some testing. The key difference between product backlog items and tasks is that tasks are actions while product backlog items are outcomes.

Sprint Planning Agenda

Traditionally, a sprint planning meeting has a two-phase structure. In the first phase, the team is committing to a set of product backlog items and crafting the sprint goal. In the second phase, the development team does a work planning session to identify the tasks they need to work on in order to achieve that goal.

A well-run sprint planning session will spend most time in the second phase where the team is tasking and work planning. If the team has a good definition of sprint ready, the first phase moves along quite quickly.

In the second phase of a traditional sprint planning meeting the team self-organizes to identify all of the work required for each of the product backlog items in the forecast. Don’t expect that the team can identify all of the work at this time, however. The nature of complex work is such that our understanding of what tasks will be needed is going to change as the team does the work. So in sprint planning, our task list is just a starting point.

After the team has broken the product backlog items down into tasks, they may decide there is more work than expected, and they do not have full confidence they can deliver the set of product backlog items they originally said they could. This is okay — we are still in the sprint planning meeting.

The development team presents the situation to the product owner, asking the product owner to remove product backlog items until they arrive at a set that the team has full confidence they can deliver. In this way, the whole team exits the sprint planning meeting with a sprint goal, a forecast, and a plan that they all believe will result in the achievement of the sprint goal.

Learn More

Posted in agile, scrum | Leave a comment

Role Of Managers In Large-Scale Scrum

Puzzled Manager With LeSS DiagramA client who is basing their scrum adoption on the LeSS scaling framework recently sent me the following question about the role of manager in Large-Scale Scrum.


I’ve read that when scaling scrum with LeSS, cross-functional teams need to have one manager. The author advocated strongly for this, but in reality, I’ve seen this fail miserably. Losing the domain owner causes the group to skew heavily to the bias of the team manager, as well as lose the ability to strongly drive and foster domain expertise. I’ve seen product people be appointed, and the tech goes to pot. Also, I’ve seen technical people not want to report up through product. I’ve seen engineers as team managers, but it’s rare to find good engineering/product people, and you have the reverse problem. I’m not completely convinced that a team manager is a good idea. Chris, what are your thoughts?


My experience aligns with yours. I think teams work best when it is clear that their product owner is the one person who directs what objectives they focus on. The development team member’s job is to work with their teammates to build a high-quality solution to the problems/objectives selected by the product owner.

The role of manager becomes much more about coaching and mentoring, not assigning work. I’ve seen it work well when individuals have managers based on their primary skill area. For example, a Java engineer having a manager who is an even more skilled Java engineer. The manager helps the contributor to improve their skills and grow into an ever more valuable contributor. The managers also anchor communities of practice (COP), sometimes called guilds. All of the Java engineers get together on a regular basis in their COP/guild to discuss things related to Java development: tools, conventions, and architectural direction. These decisions influence how they do their work, but not what work they do. Sometimes, a COP/guild identifies a technical objective they feel is important to the business and may submit requests to specific teams’ backlogs to address the issue. In these cases the COP/guild will make the business case for why the product owner(s) should have their teams pursue the objective.

Managers also have an important role in creating and maintaining an environment where teams will thrive. This usually involves working with scrum masters to identify systemic impediments reducing teams’ effectiveness and implementing interventions to improve the environment.

All of this seems to align with the description of the manager role on the LeSS website.



Posted in agile, scrum | Leave a comment