7 Scrum Guide Observations, Loopholes, And Interpretations For The Practical Agile Team

By: Mike Hall | Sep 13, 2017 |  Article,  Scrum

Man reading the scrum guide

As a 15-year Scrum practitioner, I try to revisit the official Scrum Guide, sometimes referred to as the “Scrum Bible”, to make sure I stay on top of any updates associated with the framework roles, events, artifacts, rules, and underlying philosophies. This time, I uncovered 7 interesting observations Scrum teams can use in their day-to-day activities.

#1: Developer Can Proxy The Product Owner Role

After clearly spelling out the Product Owner (PO) responsibilities such as expressing and ordering backlog items, the Scrum Guide states, “The Product Owner may do the above work, or have the development team do it. However, the Product Owner remains responsible.”

In a situation where the PO is unavailable or leaves the team, the developer could play the PO role for a short period of time. In general, we do not recommend that the Product Owner role be proxied, but it never hurts to be better prepared for unique situations such as these. One way your team could improve is to ask a developer to perform or shadow the PO role for a Sprint or two in order to better understand how the role operates and how the product vision influences the product backlog.

#2: There Is No Rule Preventing Inconsistent Sprint Durations

We all know that consistent durations for Sprints (e.g. 2 weeks) is preferred and logistically practical. I would have guessed that the official Scrum Guide makes it clear with a rule that states something like, “All Sprints must be the same length.” Not so.

What the guide does say is this: “Sprints best have consistent durations throughout a development effort.” That leaves open the possibility for a different length Sprint – but obviously only when it makes sense.

Knowing this flexibility is built in, your team can use it judiciously from time to time. For example, having a 3-week Sprint over the Christmas holidays may make sense for your team instead of following a religious 2-week Sprint. Of course, it is never a good idea to extend the length of a Sprint in order to complete unfinished work.

#3. Scrum Is Silent On What To Do With Unfinished Work Except In The Case Of A Canceled Sprint

Many teams just naturally assume that unfinished work in a Sprint automatically goes into the next iteration. Several popular Agile tools are instrumented with the default behavior of splitting unfinished work items into the current Sprint (what was completed) and the next Sprint (what was not completed). The Scrum Guide is strangely silent on where this unfinished work goes except in one specific case – when a Sprint is canceled. In this case, the Scrum Guide states, “All incomplete Product Backlog items are re-estimated and put back on the Product Backlog.”

It is probably safe to assume that the same is true even if the Sprint is not canceled – unfinished work goes back to the Product Backlog for discussion in the Sprint Review and consideration for selection in the upcoming Sprint Planning event. It is entirely possible that unfinished work from one Sprint is not selected for the next Sprint, so consider moving unfinished work to the Product Backlog to give it a chance to be discussed again within the context of your latest priorities.

#4: Sprint Goal Is Crafted During Sprint Planning After The Development Team Chooses Backlog Items

Perhaps your team starts Sprint Planning with the Product Owner announcing the Sprint Goal.  Or worse, your team does not even bother with establishing a Sprint Goal. A Sprint Goal is important because it explains why the current product increment is being built. It can also be used as a cross-check reference point for all work going on within the Sprint. The Scrum Guide says, “After the Development Team forecasts the Product Backlog items it will deliver in the sprint, the Scrum Team crafts a Sprint Goal.” As you can see, the entire Scrum Team participates. And, it follows the selection of the Product Backlog items (not before).

#5: Daily Scrum Discussion Points Are Within The Context Of The Sprint Goal

Chances are your team holds a Daily Scrum where each team member speaks about what they did yesterday, their plan for today, and discusses any impediments. Some teams use a context of the Product Backlog work item, while other teams use decomposed work (tasks) as their discussion context.

The Scrum Guide lists three topics for each developer to discuss:

  •      What did I do yesterday that helped the Development Team meet the Sprint Goal?
  •      What will I do today to help the Development Team meet the Sprint Goal?
  •      Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

As you can see, the discussions should all be within the context of the Sprint Goal. Not a task, not a story, not a work item. Your team can improve by making the Sprint Goal visible, phrasing their statements in the Daily Scrum around the context of the Sprint Goal, and ensuring there is no potential work being discussed outside of the Sprint Goal.

#6: The Result Of The Sprint Review Is A Revised Product Backlog

Is your Sprint Review a demo only? Is the result a thumbs-up or thumbs-down on what was demonstrated? The Scrum Guide says, “The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.” It describes the Sprint Review being a discussion of what was accomplished and not accomplished, problems encountered, solutions found, demo of working software, discussion of the Product Backlog, and all attendees (Scrum team and key stakeholders) collaborating on what to do next! As you can see, much more than a demo. This collaboration leads to a revised Product Backlog.

Take full advantage of having the key stakeholders present in the Sprint Review. Leave plenty of time to review the Product Backlog, collaborate with all attendees on what to do next, and yes, even adjust the Product Backlog right then and there to indicate the consensus.

#7: During Sprint Planning, Work Decomposition Is Done Only For The First Few Days Of The Sprint

This was the biggest surprise to me, a person with 15 years of experience using Scrum. As we all know, the second part of the Sprint Planning event is for the Development Team to decompose the selected Product Backlog items into a collection of bite-size chunks of implementation work. The Scrum Guide says, “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.” In other words, the Development Team decomposes only enough to cover the first few days of the Sprint during Sprint Planning. The unstated assumption is that the other work items selected for the Sprint will be decomposed during the Sprint as needed.

This approach encourages the Development Team to “swarm” the highest priority work items, completing them all the way to “done” before addressing the next set of selected Product Backlog items. However, it brings up an obvious challenge – if the team is expected to track remaining hours of work within the Sprint (as described in the Scrum Guide), how can this be done effectively unless all work items are at least preliminarily decomposed and estimated during Sprint Planning?

Final Thoughts

Let’s take it to the next level with an even deeper understanding of Scrum. By incorporating one or two (or all) of these interesting observations from the Scrum Guide, your team can improve their productivity and delivery effectiveness.  I challenge each reader of this blog to reread the official Scrum Guide. What new learnings did you find that are surprising or seldom used in your experience?

For more on Scrum and building lasting business agility, you can check out our Transformation Services page.

6 Responses to “7 Scrum Guide Observations, Loopholes, And Interpretations For The Practical Agile Team”

  1. Regarding “clearly spelling out the Product Owner (PO) responsibilities such as expressing and ordering backlog items”, I too often find that people expect the PO to write (all) Product Backlog Items (PBIs). That’s not a requirement from Scrum on a PO, but rather that whatever is in the Product Backlog is clearly understood by those that need to. As a stakeholder, I may have a filtered view that helps with Transparency (making sense of data available).

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back