Wednesday, April 24, 2013

Developing a Sprint Goal

The sprint goal is used to help focus the Scrum Team on the objectives of the sprint, the higher purpose of why the sprint is necessary. The Scrum Guide has this to say about creating a sprint goal:

"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.

By the end of the Sprint Planning Meeting, 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."

My team's Sprint Goal was, at times, essentially a summation of the user stories but the better Sprint Goals in my mind were those that served as a milestone for the development team, the customers, the business, or any combination of these. For example a Sprint Goal for the first sprint of a newly formed Scrum Team might be, "Show that we can add value to the customer using scrum." To achieve this goal the team would need to complete at least one story. You'll note that this Sprint Goal has two parts: one part is about adding value for the customer and the second part is about the Scrum Team realizing their own potential to deliver value using scrum.

In order to keep the development team motivated throughout the sprint,  I would suggest helping the team find a higher purpose and develop a metaphor to describe that purpose. Look for the benefit or who benefits from the sprint and coach the team to use this information in crafting their Sprint Goal.

During the daily scrum, I would ask the development team if any impediments might put achieving the Sprint Goal at risk. I would discontinue this once the development team themselves began alluding to the Sprint Goal in the daily scrum as they planned the day’s activities. My intent was to re-enforce the Sprint Goal as the primary focus rather than the stories, which served as a means to achieving the Sprint Goal.

The Sprint Goal and Shorter Sprints


If the sprint length is short, one or two weeks, then the Sprint Goal might not have the bite or grab the imagination as firmly as when sprints are longer. It could be that by the time the Scrum Team fully embraces the Sprint Goal, the sprint is over. The probable issue here is two-fold: 1), the development team, being technical in nature, will tend to associate themselves with the work rather than the reasons for that work, and 2), the Scrum Team may not be spending a lot of time developing the Sprint Goal for shorter sprints thinking time is at a premium.

As scrum master, you can encourage the Scrum Team to think about the bigger picture and understand the benefits and who benefits from the forthcoming sprint. The length of the sprint fades into the background as the team concentrates on these benefits. The amount of time taken to develop the Sprint Goal is rewarded by the development team gaining insight to the customer's, end user's, or business's needs, and satisfying these needs or moving toward the satisfaction of these needs is the real intent of the sprint.

Technical Sprint Goal


When the Scrum Team first formed up, Sprint Goals tended to be a reflection of the specific stories in the sprint, that is, they tended to focus on the technical nature of the sprint rather than the beneficiaries. This is most probably due to the former way software development was run using waterfall techniques. In a waterfall environment, the development team was not always privy to the reasons behind the requirements and the product owner, often a former BA, product manager, or project manager, hasn't yet learned the benefits of having development team understand the driving force or purpose behind the requirements.

In this scenario the product is the principal beneficiary of the effort rather than any customer, user, or business. The scrum master needs to show the product owner, and quite probably the business, that having the development team involved with the customers, end users, and the business is necessary to getting a better product, increasing the number of customers, and growing the business. The development team needs to understand the customer, end user, and business so better for them to put themselves in their position and visualize the customers', end users', and business's point of view.

Unfocused Sprint


Sometimes the product owner has prioritized the product backlog to do several features or functions at the same time rather than concentrating on one at a time. This probably is another throw-back to the waterfall days when all developers were kept busy on several aspects of the project at the same time. The result is that everything is "in progress" but nothing is "done".
 
There are a couple of reasons that this approach can be considered flawed. The first is this kind of approach can be construed as going against the agile principle, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." By working several features at the same time over several sprints, the team runs the risk of not delivering value at the end of each sprint. A customer may not be particularly thrilled being at sprint review after sprint review without seeing a completed feature.
 
The second potential flaw is the lack of flexibility to release early with only a partial set of planned functionality completed. For example, if a planned release has 5 new features, it's entirely possible for the business to release the product with only 3 of these completed if it can be determined that the product in its current state achieves "product/market fit." In other words, the cost of completing the remaining 2 features is greater than the perceived value of the product if these 2 were completed. If the product owner elects to do all 5 features in parallel, then the opportunity to release early, and begin generating revenue sooner, is lost.
 

Not Meeting the Sprint Goal

 
The Scrum Guide states that if the Sprint Goal becomes "obsolete", then the product owner may cancel the sprint. Since this implies a sudden, massive shift away from the perceived business value of the work in the sprint, this will be a very rare occurrence.
 
It's entirely possible for a development team to not meet the Sprint Goal but this doesn't mean the team has failed or that the sprint should be cancelled. What this most likely means is an unknown factor has made itself apparent during the sprint causing a slow-down of progress or a change in direction regarding design or technology. Not meeting the Sprint Goal is something that happens to all Scrum Teams and shouldn't be taken as a personal team failure but rather as a call to understand the root causes and correct them. Usually missing a Sprint Goal is due to an insufficient understanding of the work pulled into the sprint or, with less experienced Scrum Teams, over-committing and taking on more work than the team can handle.
 

Summary


Select a Sprint Goal that focuses on the beneficiaries of the sprint using the work as a guide. As a team, try to develop a metaphor to describe what the objective of the sprint is. Avoid the temptation to develop a Sprint Goal that reflects the work, i.e. product, over the beneficiaries.

With shorter sprints the Sprint Goal may not have enough impact on the team. The team should spend the time necessary to develop a Sprint Goal that adds meaning to the sprint even if the sprint is one week long. All sprints, regardless of length, should add value to the customer, end user, or business and the work in the sprint is a means toward achieving this value.

Try and keep a tight focus on the sprint and Sprint Goal. Working one feature at a time can get value to the customer quicker than working several features at once. It is better to have one feature "done" than to have several features "in progress" at the end of the sprint.

Do not get overly anxious if the Sprint Goal will be or is missed and don't be tempted to abort the sprint because of it. Use the sprint retrospective to analyse the root causes and make the appropriate corrections for the next sprint.
 
 

4 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Selecting a goal after picking the PBI's seems backwards in one sense. Seems like you would create a goal, then fulfill that goal by picking PBI's.

    On the flip side, the PO has ordered the PBI's, thereby telling the Dev Team what to work on, so creating a goal afterwards may be easier, unless the PBI's aren't functionally related (not an unfocused Sprint, just things in different areas that can be completed).

    During the daily scrum, you can ask the Dev Team about achieving the Sprint Goal or just about achieving the Sprint Increment. Because at the end of Sprint Planning, the Dev Team has committed (forecasted) to delivering a number of PBI in accordance with the Definition of Done and hopefully at a sustainable pace. So just ask "Are we still on-track to delivering the Increment?" Are there any impediments that will prevent you from delivering this Increment?

    Still wondering about the true value of a Sprint Goal.

    ReplyDelete
  3. Thanks for the post. Helps clarify a number of things. Something interesting in here, but that you didn't quite say--tell me if you disagree!--is that the act of creating a sprint goal can be diagnostic. For example, if the PO has laid out an unfocused sprint, trying to create a sprint goal may be very tricky. If it is, that is a sign of diffused focus. In any event, really appreciate the post!

    @anonymous: the simplest way I can state the value of a Sprint Goal is this: You never wake up and say, "Today, I am going to {insert very long list}." You say, "Today, I am going to prepare for tonight's dinner party" or "Today, I am going to retile the bathroom floor". Those are your sprint goals. The many parts to those activities are your PBIs. The value of stating goals instead of PBIs is that it helps you stay focused on what is important *as new information comes in*. If two hours before the dinner party you realize that you cannot possibly do everything on your to-do list, you can ask yourself, "is doing laundry really crucial to readying myself for the dinner party?" and adjust accordingly. If, on the other hand, you just have a long list of things to do, it is much harder to adjust. And it's even harder than that when you have a bunch of people making this decision together.

    Note: if you wake up and have no choice but to say "Today, I am going to {insert very long list}" because the items are so unrelated, then you are probably being extremely inefficient. Good idea to group the things into goals, and wrap each one up completely before moving to the next.

    ReplyDelete
  4. To 1st anonymous' point, I agree (i'm a different anon poster), the order of when to craft the Goal seems backwards. From Scrum Guide: "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal."
    It actually seems to conflict with a sentence which occurs earlier in the Scrum Guide which states: "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."
    Presumably the 'objective' mentioned is the Sprint Goal...and here it seems to be saying that the Product Owner crafts it, not the Development Team.

    ReplyDelete

Note: Only a member of this blog may post a comment.