So the answer is . . .

A minor update for Sprint Planning in late 2019!  At some point planning for planning needs to give way to planning.  Planning identifies a goal and helps to envision the steps needed to attain that goal. In Agile, the planning event also sends a message about the amount of work a team anticipates delivering in an iteration. While every team faces variations based on context and the work that is in front of them, a basic planning process is encapsulated in the following simple checklist. (more…)

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 542 features our interview with Kevin Rush. Mr. Rush has developed an innovative approach to facilitate sprint/iteration planning.  Kittens, exploding kittens, and fat cats are used to help teams probe whether the team understands the story and if the story is broken down well enough for the team to reduce the risk of failure.  All change agents talk about making changes at the team level but many fail to change how they work, Kevin suggests that experimenting with different approaches is eating our dog food. Way too many pet metaphors, but a great discussion.

Kevin’s Bio

Kevin is a certified Scrum Master and Agility Enablement leader at Hyland Software. Before coming to Hyland he worked as an innovation consultant and coach with for-profit and nonprofit organizations throughout Northeast Ohio. A graduate from DeVry University he spent time as Technology Coordinator for several local school districts before transitioning to ministry then back to tech! When he’s not working with teams and organizations he spends his time with his beautiful wife, Sondra, and their three beautiful daughters. (more…)

Longer isn't necessarily better.

Longer isn’t necessarily better.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project. As a general rule, once a team or a team of teams has settled on a specific cadence they tend not to vary significantly. While In today’s business environment a plurality of teams and organizations use a two-week sprint cadence, there is often a lot of angst over the finding the exact number of weeks in a sprint any specific team.  Many organizations adopt a standard and take the discussion off the table. With any specified cadence duration, there are typically three complaints: too much overhead, not getting stories done and not being able to commit resources on full-time basis to the work. In almost every case the complaint is coupled with a request to lengthen the duration of the sprint and therefore to slow the cadence.

  1. The sprint structure requires too much overhead: Sprints begin with a planning event and typically complete with both a demonstration and retrospective. Short stand-up meetings occur daily. Some team participants view these events as overhead. Scrum practice and observation of teams strongly suggests that the effort for the Scrum events increase or decrease depending on the length of the sprint. Longer sprints tend to require more planning and lengthier demos and retrospectives.  As a rule I suggest two hours of planning per week and 30 minutes each for the demonstration and retrospective per week in a sprint. Stand-ups should be approximately 15 minutes per day. For example, I would expect to spend 3 hours 45 minutes (2 hours for planning, 30 minutes for demo, 30 minutes for the retrospective and 45 minutes for 3 stand-up meetings) on events in a one-week sprint and 8 hours (4 hours for planning, 1 hour for the demo, 1 hour for the retrospective and 2 hours for 8 stand-up meetings). I have noticed that the effort for sprint events that are more than three weeks long tend to take longer than one would expect (four weeks sometimes being more than twice what is expected). Realistically, sprint size should not significantly affect overhead until you get to sprints duration’s of four weeks or more therefore overhead is not an obstacle to shorter sprints. Remember that in earlier posts we have shown that shorter sprints deliver feedback and value sooner so therefore are preferred all things being equal.
  2. Our stories can’t be completed during the sprint. This is typically not a problem with the duration of sprint, but either an issue of how the stories are split or a process problem. One typical corollary to this complaint is that the team can’t break stories into thin enough slices to complete. Most of the time this is a training or coaching problem rather than a technical problem, however in highly regulated environments or systems that affect human life I have seen scenarios where stories tend to require longer sprints due to very specific variation and validation. One common cause of this problem is assigning and hard wiring roles (testers can only test for example), which can cause bottlenecks and constraints if there is any imbalance in capacity. This is illustrated by the Theory of Constraints (take a look at our Re-read Saturday entries about The Goal for more on the Theory of Constraints). Typically, longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance because more stories are started and are subject to bottlenecks and constraints.
  3. Our organization can’t commit full-time resources to a sprint. Part-time team members typically have to time slice, switching between projects and pieces of work leading to some loss of efficiency. This is a reflection too much work and not enough capacity causing delays, constraints and bottlenecks. Similar to issue 2 above, typically longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance for the same reasons as noted above.

Many problems with cadence are either a reflection of process problems that generate overhead or poorly split user stories. For example, teams that do not have a groomed backlog will need to spend more time planning. Some team members see planning as avoidable overhead (the just wing it mentality). Overly large teams tend to have long daily stand-up meetings, again typically seen as overhead. Stories that are not thinly sliced will take longer to complete and have higher propensity to get stuck giving the team a feeling that a longer sprint is better. In almost every case, thinly sliced stories and committing to less work tends to improve the flow of work so that the team can actually deliver more. The duration of the sprint and cadence are usually not the root cause of the team’s problems.

Burn down chart

Burn down chart

I have been asked more than once about what to do with tasks that occur during a sprint that are not directly related to a committed story.  You need to first determine 1) whether the teams commit to the task, and 2) whether it is generally helpful for the team to account for the effort and burn it down.  Tasks can be categorized to help determine whether they affect capacity or need to be planned and managed at the team level.  Tasks that the team commits to performing need to be managed as part of the teams capacity while administrative tasks reduce capacity.

Administrative tasks.  Administrative tasks include vacations (planned), corporate meetings, meetings with human resources managers, non-project related training and others.  Classify any tasks that are not related to delivering project value under administrative tasks. One attribute of these types of tasks is that team members do not commit to these tasks, they are levied by the organization. The effort planned for these tasks should be deducted from the capacity of the team.  For example, in a five person team with 200 hours to spend on a project during a sprint (capacity), if one person was taking 20 hours of vacation the team’s capacity would be 180 hours.  If in addition to the vacation all five had to attend a two hour department staff meeting (even an important staff meeting), the team’s capacity would be reduced to 170 hours.  Administrative tasks can add up, deducting them from capacity makes the impact of these tasks obvious to everyone involved with the team.  Note: in organizations that have a very high administrative burden I sometime draw a line on the burn down chart that represents capacity before administrative tasks are removed. 

Project-related non-story tasks. Project-related non-story tasks are required to deliver the project value.  This category of tasks include backlog grooming, spikes and retrospectives.  There is a school of thought that the effort for these tasks should be deducted from the capacity.  Deducting the effort from capacity takes away the team’s impetus to manage the effort and the tasks. This takes away some of the team’s ability to self-organize and self-manage. The team should plan and commit to these tasks, therefore they are added to the backlog and burned down. This puts the onus on the team to complete the tasks and manage the time need to complete the tasks. As example if our team with 170 hours of capacity planned to do a 10 hour spike and have three people perform sprint grooming for an hour (total of 13 hours for both), I would expect to see cards for these tasks in the backlog and as they are completed the 13 hours would be burned down from the capacity.

Tasks that are under the control of the team need to be planned and burned against their capacity.  The acts of planning and accounting for the time provide the team with ability to plan and control the work they commit to completing.  When tasks are planned for the team that they can’t control, deducting it from the overall capacity helps the team keep from over committing to work that must be delivered.   

Listen to the Software Process and Measurement Cast 289. SPaMCAST 289 features our essay on sprint planning.  The essay begins:

It is often said that well begun is half done. In other words a good start contributes to a good finish (at least according to Mary Poppins). In Agile projects sprint planning is an important first step towards delivering value effectively. The planning process provides teams with an understanding of what needs to be delivered in the next increment of time and provides a platform for deciding on the approach they will take based on the up-to-date knowledge they developed during the previous sprint. Well started might not be the whole battle but it certainly makes the rest easier.

Listen to the rest of the essay on the SPaMcast 289.

Also on the SPaMCAST 289 Kim Pries is back with his “The Software Sensei” column. In this installment Kim’s essay is titled Schedule Cycles.  In the essay Kim talks about tasks and scheduling.

I have shortened the introduction of the cast this week. I would like your feedback. Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Jan Beaver, author of the Agile Team Handbook. Jan’s book provides team members with the resources needed not only to become Agile but to practice Agile.

Upcoming Events

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!


Upcoming DCG Webinars:
May 22 11:30 EDT – Agile User Stories
June 19 11:30 EDT – How To Split User Stories
July 24 11:30 EDT – The Impact of Cognitive Bias On Teams

Check these out at

I look forward to seeing or hearing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Periodic grooming keeps the number of knots down!

Periodic grooming keeps the number of knots down!

Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time (although some times are better than others).

In Agile projects, the backlog is a dynamic representation of business and technical needs. Backlogs can be the expressed needs of a single project or the long term list of needs for an application that will be delivered over many projects. In many organizations anyone (business analysts, developers, users, customers and other stakeholders) can add items to backlog. Given the wide variety of uses and sources of the backlog, grooming is a critical process. Grooming ensures that each story is understood and qualified for inclusion on the backlog. The grooming process reviews how a story is constructed and makes sure that it is properly formed. Grooming also enforces prioritization of the backlog. If a story is going to be worked on soon, the process helps to make sure it is granular enough to be incorporated into a sprint.

In most Scrum-based projects that are past the initial backlog formation, backlog grooming is preformed formally as a periodic event held a few days before the sprint planning meeting. Informally, backlog grooming can (and does) occur during any discussion of the backlog items. In Kanban implementations, backlog grooming is more of a continuous event. Grooming occurs as the immediate backlog (the immediate backlog are the items that will be worked on as soon as capacity is available) is replenished so that the team does not run out of work that is ready to be pulled onto the board.

As the backlog is created, initially the process of grooming often requires a significant amount of effort in order to establish an initial understanding and prioritization. Once established, formal backlog planning becomes less of a burden. Mike Cohn suggests that backlog grooming can consume 5 – 10% of the effort in each sprint. My observations of Agile teams (both Scrum and Kanban) that are past startup do not require that much effort for formal grooming activities, however the amount of formal (and informal if that were measurable) is not insignificant and is variable.

Whether backlog grooming is practiced as an event or as a continuous process, the goal of the activity is to make sure that the team has a list of well-formed stories in priority order ready to be worked on. Grooming does not replace planning, but is a predecessor. However, the process is not free. Effort is needed to perform backlog grooming.  The amount of effort depends on the state of the backlog and where you are in the project life cycle, however grooming pays off. Groomed stories can be more easily planned (more information on sprint planning), accepted in to the sprint and then accomplished.



Any discussion of planning can lead you to believe that the plan is the end rather than the means to that end. Not true. We plan for many reasons.

  1. We plan so that we visualize attaining a goal.
  2. We plan so that we anticipate the path toward the goal.
  3. We plan together so we create a common vision.
  4. We plan just enough so that change does not destroy us.
  5. We plan so that others can be confident in us.
  6. We plan so that we can motivate each other.
  7. We plan so the we can hold each other accountable.
  8. We plan so that we can understand our capacity to deliver.
  9. We plan so we can talk about what we can deliver.
  10. We plan because the perception of random action generally causes panic in the management ranks.

Sprint planning is a tool to help Agile teams develop a map forward towards the real goal of software development – the delivery of value. We have to refine that map as we gain experience and learn every daily, every sprint and every release.

Use tools to keep the whole team engaged.

Use tools to keep the whole team engaged.

Distributed Agile planning is not any different from non-distributed in terms of its goal and process.  What should be different are the techniques and amount of facilitation.  Before we go further, I do not think there is any reason planning can’t be done amongst a distributed team. I do not believe there is any need to change the time parameters.  However, both of these statements are true only if the team stays engaged and the Scrum Master provides active facilitation.  The single biggest hurdle when a distributed team is involved in planning is keeping everyone engaged.

Visualization is a powerful tool to help foster engagement.  There are two types of visualization that are important.  The first and simplest is that all team members should be able to clearly see what is being discussed.  For example, I recently participated in an internal sprint planning meeting.  We used a screen sharing software that everyone on the team used.  As a story was discussed and planned, we brought it up on the screen so that everyone in the session could refer to the same set of words. Tasks, as they were identified, were typed directly into a shared document on the screen.  A second form of visualization relates to the team.  Use video on top of any screen sharing tools.  Seeing people as they discuss a point or talk about a story imparts significantly more information that just hearing them.  Think of how different the typical experience is when listening to radio compared to television.

IT personnel tend to be gadget and tool aficionados.  While a good tool for seeing the backlog or Kanban board is critical (emphasis on good, there are some re-purposed waterfall tools I would avoid like the plague . . . actually I might consider the plague first), the process needs to be simple enough that the set up time does not eclipse the planning time.  Tools like mind mapping software can be very useful to quickly capture and organize information. I personally use several including FreeMind (free and open source).  Another simple tool is Mountain Goat Software’s planning poker site at  I strongly suggest Scrum Masters (or coaches) walk through the tool suite they will use during planning before “going” live.  A simple check list of tools I use is:

  1. Screen Sharing Software: Tool examples include Webex or the like
  2. Video: Software examples include Skype Pro and OOvOO.
  3. Backlog/Kanban Boards: Examples include LeanKit, Kanbannery and Trello.
  4. Mind Mapping Tools: Examples include iTHoughts, FreeMind and Astah.
  5. Planning Poker Tool:
  6. Egg timer (or sometimes the timer on my phone)

The last item is capitalized because all bets are off if team members can’t hear each other.

Once the team has gotten over the hurdle of using the communication tools, the final problem is one of facilitation.  The Scrum Master needs to facilitate the process with special emphasis on making sure everyone participates and stays engaged.  They also need to pay attention to pace.  I use an egg timer to remind everyone of both the overall time box and the time box needed for planning each unit of work.

In distributed Agile, the planning process does not change.  However, keeping everyone engaged might be more difficult. The Scrum Master can make engagement more likely by making the process as easy as possible and making the process as personal as possible.  Planning is still a whole team sport, make sure that the whole team participates, no matter where they are.

0515131837Sprint planning is an important step in the process of delivering work in efficient and effective manner.  Unfortunately sprint planning is not always done well. When it is not done well it can yield less than wonderful results.  Four common problems are:

  1. Planning sessions are tedious.  Planning sessions where the team is struggling to understand the unit of work either due to lack of knowledge (including lack of acceptance criteria) tend to take forever . . . and ever . . . and ever.  Trying to develop the perfect plan and estimate will generally cause the same time dilation effect. Effective and efficient planning sessions are the outcome of units of work being groomed and prioritized and being understood or quickly explainable by the team. It is also important that the process is paced correctly and time boxed, which is the responsibility of the Scrum Master.  The session can always end early if you are done.
  2. Only part of the team participates in planning. As mentioned before, sprint planning is a team event – a whole team event. Letting individuals plan their own activities, breaking into subgroups and then planning, letting remote team members not participate or any combination of the later is a problem. Any of those scenarios will have negative consequences for the team, ranging from knowledge hoarding and holding onto specialties, to lack of esprit de corps. This “this is mine and that is yours” mindset for units of work will end in planning gaps.  Scrum Masters or coaches need to exert all of their influence to ensure the team plans as a team, and in a broader sense, that the team gels so that it does not act like a group of individuals.
  3. Planning sessions lose focus. I recently observed a sprint planning session that veered off track as team members began debating the merits of using as platform versus another cloud provider. It was fun, BUT not relevant. Teams lose focus because of a lack of preparation.  A backlog that is not prioritized or groomed or a sprint without a goal can let the attention of the team wander.
  4. Roosters in the hen house! Roosters are outsiders that participate in sprint planning and provide unwanted, unneeded and distracting advice to the team.  Sprint planning is a team activity. Planning should represent the needs of the product owner and the skills and capabilities of the team.  Teams that are brow beaten by outsiders into taking more work than they can accomplish or into doing work that does not represent the needs of the product owner will lead to ineffective planning session due to lack of team knowledge or worse, a lack of motivation.

When team members begin to look forward to sprint planning with as much anticipation as a root canal, something has gone wrong.  One of the most serious and easily fixed problems is lack of preparation. Lack of preparation has many consequences, none of which are good.  The hardest issue to deal with is the presence of ‘roosters’ in sprint planning, usually because the ‘rooster’ often has enough positional power to make it difficult to run them off.  The Scrum Master needs to shoulder the responsibility for helping the team to recognize and rectify all of these potential problems.  Scrum Masters and coaches of the world facilitate the process, make sure the team you belong to is prepared, stays focused and if absolutely necessary, meets in an undisclosed location.

Having common goals and definitions helps to lift the fog.

Having common goals and definitions helps to lift the fog.

The first two articles on sprint planning have sparked a number of interesting side conversations about logistics and precursor concepts.  There are several constraints, concepts and ideas that the team needs to keep in mind to facilitate effective sprint planning. For good planning, all teams must understand the goal of the sprint they are planning, the definition of done and the time box for completing planning. 

The sprint goal (or goals) is the high-level business and technical target for the sprint.  The goal acts as an anchor that roots the units of work that product owner will ask the team to complete in the upcoming sprint.  The sprint goal is a touch point that each team member can use to make the moment-to-moment decisions every development team makes. The goal can also be used as a communication vehicle to help stakeholders and others outside the team understand what will be delivered during the sprint.

The second concept all teams must understand prior to beginning sprint planning is the definition of done. The definition of done represents both the team’s and organization’s expectations of the state of the functional software when the sprint is complete. For example my standard definition of done is:

  • Design documents developed (if needed)
  • Code written
  • Required code comments written
  • Unit tests preformed
  • Integration test executed
  • Release notes developed
  • Acceptance criteria met

The unit of work is not done until all of these criteria are complete.  Every organization will have its own list of macro tasks that are required to show demonstrable value.  For instance, my base list includes design documents. Several of my clients are contractually required to produce design documents.  Without the design (or with an incorrect design document), they will not be able to deliver the software and get paid.

Third, the whole team needs to understand the planning time box.  As a general rule, the preplanning meeting should last no more than an hour for a two week iteration (30 minutes for a one week iteration).  The main planning session should be planned to last no more than two hours for each week of sprint duration.  The time box helps teams stay focused (also keeps me from telling stories), and from being overly precise (which usually represents false precision), which can cause the team to spin into planning paralysis. When the clock strikes the planning time box is over and the team needs to start executing.  The plan will be revisited during the daily meeting.

Teams need to begin planning with a firm grasp of sprint goal to provide direction and focus.  Explicitly understanding the expectations for what done means will help the team plan activities and tasks.  The definition of done also helps the team keep each other on track because they all have common expectations.  Finally, planning like most team sports, is constrained by a clock.  The time box keeps the team from spending the entire sprint planning rather than delivering.