8 reasons why the the Sprint Goal is highly effective to deliver value

The Sprint Goal, as defined by the creators of Scrum, is a selection of product backlog items that form one coherent feature, which helps a development team to work together rather than pursue separate initiatives. Ian Mitchell, a writer on agile software development, summarizes the usefulness of the Sprint Goal by writing the following statement on a blog post:

What we are getting at here is that the whole purpose of a sprint is to meet a Sprint Goal, and Scrum is framed to support sprint-based delivery. Take away the Sprint Goal and the rationale for using Scrum disappears with it. You might as well operate on the basis of continuous flow. Without a Sprint Goal to meet, sprint backlogs can serve no useful purpose.

The Sprint Goal is a description of the coherent increments that will be delivered at the end of the sprint and it provides guidance to the development team on why it is building an increment and how it should do so. If the development team discovers that they won’t be able to deliver that coherent feature during the sprint, they can negotiate the scope with the PO.

We can go even further by describing all the advantages of a well defined Sprint Goal and how it helps to get things done effectively. It helps …

  • The team to understand the purpose of their work beyond the description of individual PBIs, which stimulates intrinsic motivation and compliance. This leads to better implementation as the team can keep the big picture in mind. A well known man built an empire on this concept alone.
  • To keep the team focused on a small objective and avoid the negative impact of context switching. It can be seen as mini projects. These are clearly achievable multiple goals instead of a big one that is divided into chunks used to fill sprints (Waterfall disguised as Scrum). Focus is a very important concept to understand when you work with knowledge and creative workers (in the case of the vast majority of people in software development); it is probably the most important thing to work on in order to deliver value and quality to your customers.
  • The team to collaborate on a single objective with required flexibility and empowerment (cohesion vs individualism). This leads to better shared responsibility as the success of the sprint will be evaluated based on whether the goal has been met, instead of counting all the individual tasks that can lead to individual developer comparison in the worst implementation of Scrum. This helps in getting cohesion which is the most important factor for a high performing team.
  • The PO provide clear value beyond the selected product backlog items (PBI) and therefore improve prioritisation. This helps getting a realeasable product increment at the end of each sprint, which is the whole point of agile software development.
  • The PO to communicate on progress based on working software, instead of a percentage of a list of individual tasks that means nothing to the customer. This also helps to create a valuable roadmap to communicate to users.
  • The PO to get structured feedback from each meaningful increment instead of individual tasks. This provides the next sprints with new insights which automatically leverage the power of Scrum or any other iteration based framework.

The Sprint Goal, when properly used, is a proof that Scrum is understood and correctly implemented. Together with the (potential) release of a new product increment, this makes the Scrum Sprint really useful. Therefore, this is the first thing I check when I’m asked to audit an existing Scrum implementation. Sadly, this is the most overlooked artifact of Scrum, so if you begin a new implementation, start with the sprint goal and explain why it’s useful.

Incoming search terms:
  • areakjc
  • OND7

“Scrum in 10 slides” presentation has been updated

When I created the first version in 2012, I never suspected such a success. After a few years of practice in agile coaching and the resulting deeper understanding of the Scrum framework, I decided to update the slides with the latest changes from the official guide. I also decided to focus on some of the things that are not well understood in the many Scrum implementations I’ve had to observe.

First, Scrum is not always adapted to the environment that wants to implement it. Prior work on mentalities must be done. I specified that the Scrum Master was responsible for leading the entire organization towards that. The role of the Scrum Master is also in my experience, the most misunderstood element in the framework. Its related slide has been updated to allow you to explain what exactly a Scrum Master is doing on a daily basis.

Then, I also noted that important steps in the Scrum process were deliberately forgotten, often for lack of understanding of their usefulness. I added the notion of visibility and transparency of the backlog on the slide of the Product Owner but also the fact that the Definiton of Done could be the result of a reflection at the level of the entire organization. The slide on the Sprint Planning was already very clear about the usefulness of the Sprint Goal, but the importance of the latter is put more in the slide of the Daily Scrum which is undoubtedly one of the most important Scrum event but usually badly conducted by the team.

Finally, I made some minor corrections, for example in the elements related to the Development Team, the practice of Backlog Refinement which should not exceed 10% of the team’s time during a sprint or what is a Product Owner.

This should now allow you to address the most important elements of Scrum fairly quickly. If you have comments about the content or if you notice an error on one slide or the other, do not hesitate to let me know.

Download the latest version here.

The actor–observer asymmetry

There is a difference of judgment in any activity depending if we are an actor or an observer (Malle, Knobe, Nelson 2007). I realized this fact when I was practicing martial arts, long before my studies in psychology. The audience, usually parents, downplayed the difficulty of the discipline and very often judged the activity incorrectly. One of the most common expressions was, “but it is only dancing.”

This comment annoyed many of the new practitioners, but not the more experienced who knew that this was a gross misjudgement. You could see the difference when these same people decided to try the discipline once. As you can imagine, most did not usually go beyond the first attempt as it was physically demanding and much more difficult than they had imagined. Their judgement of the activity observed radically changed when they became an actor.

In our everyday life, we alternate between the positions of observer and actor. In both situations, we make judgments and many of the various decisions we take are based on them. As an observer, we can judge incorrectly the behavior of others. As an actor, we take into account the judgment of observers. It is important to recognize these situations and act accordingly.

Let’s take a concrete example: starting a software business. This is a subject dear to my heart as I far too often watch the growing disillusions of entrepreneurs when they take in the reality of things. As the disillusionment grows, only those predisposed (very rare) or those working for pleasure keep going.

The reality is that entrepreneurs work very hard and take on tasks that we would probably never have agreed to do as an employee.  You must also be aware that very few projects succeed at first; most stop after the first failure.

When we see talented entrepreneurs in the newspapers, we think it’s easy and as simple as registering a domain name, writing 10 lines of code and then selling your company for millions. The reality is that most successful people have worked hard, often in physical and psychological pain, for many years and have faced all kinds of problems. They made the difference by persevering. All my successes have been preceded by hard work and pain.

It is difficult to realize this when you have not been there yourself. But how do you know before you make a judgement or take an important decision?

The first step is certainly to become aware of any bias and take it into account. It is very difficult as these behaviors are unconscious and judgment is rooted in how we operate.

When you realize that you are in an observer’s position and about to judge and eventually take a decision, you should not be satisfied with the information available. As you may have noticed, observing is insufficient to get an opinion, even if one is aware of the bias. Failing testing it yourself (and you can’t start a business as a test in the same way you can attend a single martial art class), the only solution is to ask questions of the actors. Those who have experience in the field or are in the situation. Do not just question one of them. The more people you question, the more relevant your information.

The only concern with this approach is that it can block you from moving forward. Indeed, if you ask too many questions you can start to stagnate. Everyone now knows that one of the primary qualities of an entrepreneur is his ability to move forward quickly. Many are also characterized by a certain impulsive trait which will be discussed in a future article.

Awareness of the actor / observer asymmetry is directly related to critical thinking: identifying biases, separating fact from opinion and analyzing data. Awareness of our mental functioning is, again, the key.

Why the sprint review is important to developers

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

  • For performance improvements, clearly indicate the gain in a metric understood by the user.
  • If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
  • For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered – this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

  • draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
  • This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
  • Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
  • Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.
Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement – and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

  • Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
  • Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

  • You can show your progress and all your activities
  • Feedback is an opportunity for you to excel in your profession