Scrum Self-Assessment

072516022-assessment-teared-note-paper-p.jpeg

Scrum is simple but not easy. It consists of a set of roles, events, and artifacts that together comprise the Scrum framework. A team’s level of success with Scrum depends on how well the team engages in the Scrum framework and how they inspect, adapt, and improve over time.

To begin this self-assessment, I would like you to imagine where you would like to be in your software delivery capabilities sometime in the future. It does not matter what the details are, but they should include elements of quality, schedule, budget, and predictability. Assign a value of 10 to your desired future state.

Now, assign a value to your current state. For example, you know you want to achieve a 10, but currently you might be a 4. Next, determine what your state was three months ago, six months ago, and nine months ago.

Review that data and see whether you are improving in your journey toward your self-described future state. Perhaps you have been in the same state for some time now and are not improving. Keep your state in mind as you complete the rest of this self-assessment.

This article identifies the key principles of Scrum and allows the reader to rank their Scrum adoption on a scale of 0 to 4. A 0 means no or very low acceptance of the principle. Beyond 0, we have a ranking of 1 to 4, with 1 representing low adoption and 4 representing very high adoption.

This scale can also be used by teams who are new to Scrum. In this case, the ranking would be how open your new team is to implementing the principles in the proper manner. Keep the current culture of your company in mind as you perform the ranking. It will help you understand the consequences of skimping on areas.

Each area of Scrum is covered in this assessment. We start with a short description to provide context as to why it is important and to aid the reader in deciding on a ranking.

Product Owner Engagement

The product owner is a key member of a Scrum team. The product owner should have a passion for the product they are responsible for. They should understand the competitive landscape of the product and engage stakeholders on a regular basis. It is the job of the product owner to ensure that the product meets the needs of the organization and is the single neck to ring if the product’s features are incorrect.

The product owner is responsible for the product backlog. The backlog is a prioritized list of product features knows as user stories.

The product owner ensures the user stories are properly defined, estimated, and prioritized. They schedule backlog grooming meetings at the proper time to ensure the backlog is in the proper condition for sprint planning.

The product owner offers high availability to the Scrum team to answer any questions that arise. They are ready to attend demos and accept user stories as DONE.

The product owner is prepared for and attends all sprint review meetings. They pay close attention to the demos and provide feedback to the team. They also accept user stories as DONE.

A product owner who is not fully engaged causes friction and slows things down. Sprints unfold quickly, and if the product owner is not available to the team, stories will not get DONE in a sprint.

If the product owner does not keep the backlog in order and is lax on the scheduling of grooming meetings, sprint planning suffers.

If the product owner misses sprint review meetings, user stories cannot be approved and set to DONE.

0 | 1 | 2 | 3 | 4

Definition of DONE

One of the twelve principles of the Agile Manifesto is “Working software is the primary measure of progress.”

The definition of DONE expands this idea and defines the exact criteria that allow a user story to be considered DONE. From a delivery perspective, these criteria typically include “fully developed”, “QA-tested,” and “deployable”. They can also include additional elements, such as “unit-tested,” “code-reviewed,” and “stress-tested.” The team identifies the completed criteria together. The final DONE criteria item is accepted by the product owner.

When a well-identified definition of DONE is used, a tremendous amount of risk is eliminated. When a team can truly identify a set of features as DONE, they can move forward and check these items off their list. There are no odds and ends and no “one-line changes” to features that pile up.

I want to emphasize deployable, which was highlighted earlier. A user story is not DONE when it runs on a developer’s machine. It must operate properly in other environments as well, like QA and ultimately production. When a user story is truly deployable, it eliminates the oft-stated quote “It works on my machine”.

The DONE criteria are considered when defining and estimating user stories. The whole team must keep this concept in mind. This point will be emphasized throughout the rest of this article.

The biggest consequence of a poorly followed definition of DONE is risk. There is a risk that things we thought were done are not really DONE. The problem is, we do not know how many of these things there are.

Typically, the launch date looms over the team, and team members work many overtime hours to meet the deadline. When this happens, quality suffers. Over time, after multiple launch cycles, we have a fragile, buggy software product.

0 | 1 | 2 | 3 | 4

User Story Definition

The most efficient Scrum teams define user stories using the INVEST approach. The most important letters from this acronym are I (independent), E (estimable), and S (small). As stories are defined, the definition of DONE must be considered.

When stories are independent of each other, there is much more flexibility in how they can be developed and deployed. Often, proper architecture is required in the product so that components, portions of web pages, and the underlying architecture can operate independently.

We cover estimation in the next section, but it is worth mentioning here since it is part of the INVEST acronym. As the independent stories are defined and prioritized on the backlog, they must be easily estimated, meaning they must be understood by the team.

Small stories are easier to understand and get to a DONE state in the fast-moving sprint execution cycle. At a very minimum, a story must be able to be completed in a sprint.

Microservices are a common way to tackle independent and small stories.

When stories have tight dependencies, friction occurs and stories are harder to deploy to production. When legacy monolithic systems are involved, the dependencies can be treated as technical debt and be prioritized on the backlog like any other user story.

When stories are large, the likelihood of not completing stories in a sprint is higher. Often, these large, incomplete stories move from sprint to sprint, making planning difficult. Large stores may be split into smaller ones. It is better to complete a few of the small stories and have an incomplete small story move to the next sprint instead of one large one.

0 | 1 | 2 | 3 | 4

User Story Relative Size Estimation

To properly plan, we need an estimated backlog. A popular technique is to estimate user stories in a relative manner. The definition of DONE must be considered when estimation is performed.

The most common technique is story points. This technique assigns a point value to each user story using a Fibonacci-like format: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Estimation is done by the team, typically during backlog grooming. Planning poker is a common Scrum game where this occurs. During a planning poker session, each team member votes for their estimate by holding up a card with an estimate value on it. When large discrepancies occur between team members, the story is discussed until a consensus is reached.

A simplified approach known as T-shirt size may be used. This technique is good for new teams. Using this approach, the story point value is assigned by associating it with the size of a T-shirt. (Baby - 1 | Small - 2 | Medium - 4 | Large - 8 | XL - 16).

When teams do not estimate user stories, it is not possible to properly predict delivery dates or budgets. In this situation, the team works hard on user stories with no real idea of when they will be able to ship a release. This often leads to a death march toward the end of the release, when management instructs the team to “do what it takes” to get the product shipped by some arbitrary date.

0 | 1 | 2 | 3 | 4

Backlog Grooming

Backlog grooming is not a formal Scrum event. The goal of backlog grooming is to get the backlog into a state that will allow sprint planning to be successful. The frequency of this type of meeting is up to the team. The product owner conducts the meetings. The following activities should be accomplished:

  • Priority – the priority of the backlog is reviewed and modified as needed. Keep in mind that the stories at the very top of the backlog will be considered for the next sprint.

  • User Story Definition – new or drastically changed stories are explained by the product owner. The team interacts with the product owner and asks any questions necessary for a full understanding.

  • User Story–splitting – when a story is large, it is split into smaller stories.

  • Estimation – stories are estimated using a relative size technique.

Teams with a well-groomed backlog will be well prepared for sprint planning.

When a backlog is not well-groomed, sprint planning is compromised, which causes major disruptions in the Scrum process. The team cannot accurately commit to sprints, and long-term planning becomes nearly impossible.

0 | 1 | 2 | 3 | 4

Stable, Cross-functional Team

A scrum team focuses 100% on the work in a sprint. They do not perform any other work. This is one of the primary reasons that scrum teams can get much more work done than in other frameworks. Scrum teams should be small, typically six to eight people.

A scrum team should have all the skills necessary to complete the sprint. When skills are needed outside of the team, friction and dependencies arise.

Pict1.png

Individual team members should be cross-functional, which is known as T-shaped skills. Broad skills allow individuals to perform a variety of tasks. Deep skills are specialties that only specific team members are qualified to do.

An example of a broad skill is helping author user stories. Most team members have this skill. A deep skill is UX development, which is a specialty specific to a small number of team members.

The makeup of the team should not change and should remain stable. Team members learn how to work together over time and develop a rhythm that improves efficiency.

When teams and individuals are cross-functional and stable, an accurate velocity emerges, which is critical to planning and budgeting.

If team members are often shuffled off the team and if individuals only work on their specialty skills, velocity is all but impossible to utilize for planning purposes.

0 | 1 | 2 | 3 | 4

Sprint Planning

Sprint planning is where the team decides what can be completed in the upcoming sprint. Many of the topics we have discussed come together during the sprint planning. The level of success will depend on how well the team has accomplished these aspects we have already discussed.

In a nutshell, the team reviews the user stories at the top of the backlog one by one and adds them to the sprint until there is no more capacity available in the sprint.

This process is easy when the backlog has been properly groomed. Velocity is used to help determine what stories will fit into a sprint. If your team has a velocity of 75 story points, you simply add stories to the sprint until you reach 75 points. If the team is not stable and cross-functional, the velocity will not be accurate, and planning will be much more difficult.

Some teams use hour estimates to help determine what will fit into a sprint. In this case, individuals estimate in person-hours how long each task necessary to implement a user story will take. The total number of hours is compared to the team’s available hour capacity. When the hour capacity has been consumed, no more stories are added to the sprint.

Sprint-planning meetings are crucial. When this meeting has not been properly executed, the pending sprint is at risk of inefficiency and waste.

0 | 1 | 2 | 3 | 4

Sprint Execution

Once a sprint has begun, it is largely up to the team to self-organize and successfully deliver the user stories agreed upon during the sprint planning.

There is one daily meeting required in the Scrum process. This meeting occurs each day at the same location and is time-boxed to fifteen minutes. It is often called a stand-up meeting because everyone stands, which keeps the meeting short.

In this meeting, each team member discusses what they have worked on since the last meeting and what they plan to complete by the next meeting. They also mention any impediments they are experiencing.

Pict2.png

The team also reviews the progress of the sprint using a burndown chart. This chart compares the initial estimate at the beginning of the sprint to the current daily estimate.

This meeting provides the team with a daily view of the work remaining in the sprint. Based on the data in the chart, action may need to be taken to meet the desired goals.

Since sprint execution takes up most of the time in a sprint, much of the Scrum Master’s work unfolds here. The Scrum Master ensures that Agile principles are followed and removes impediments the team may have.

Sprint execution is where the rubber hits the road. Any deficiencies that occurred are exposed here. Poor sprint planning, an improper definition of DONE, and team deficiencies are exposed.

0 | 1 | 2 | 3 | 4

Sprint Review

The sprint review is where the team demonstrates the user stories that are DONE and awaiting product-owner approval. The team decides who will perform the demonstration. The product owner is a key attendant to the meeting because they must approve the stories for them to be considered DONE.

We do not have to wait until the sprint review to demonstrate stories; they may be demonstrated to the product owner anytime and be approved.

When a user story is considered DONE, the story points associated with the story are added to the team’s velocity. If any of the DONE criteria are incomplete, the story is not DONE and typically moves to the next sprint. No story points are added to the team’s velocity in this case.

If the product owner is not engaged and misses sprint review meetings, stories cannot reach a DONE state. Unapproved stories move to the next sprint and get entangled with the stories that are planned, which causes unnecessary noise and distraction. It also affects the velocity calculation of the team.

0 | 1 | 2 | 3 | 4

Sprint Retrospective

The sprint retrospective is where the team reflects on the sprint that just ended and identifies a few things that went well and a few things that need improvement.

We want to continue doing the things that went well and improve on the things that did not go so well. The team agrees to improve on two or three things in the next sprint.

Teams that embrace the retrospective step improve over time. Teams that skip the retrospective step or take it lightly do not improve and actually degrade over time.

0 | 1 | 2 | 3 | 4

Scrum Master – Servant Leadership

The Scrum Master works with the Scrum team and guides them in their journey to adopt Agile and Scrum principles. The Scrum Master is not a boss or a project manager but rather a servant leader.

Some attributes of a Scrum Master as a servant leader are as follows:

  • Makes observations and asks questions about things that violate Scrum and Agile principles and helps people overcome obstacles on their own.

  • Provides direct and firm feedback.

  • Understands that change is difficult and employs empathy while guiding the team in making the necessary changes in behavior.

  • Acknowledge when things are outside their scope of knowledge and skills and recommends other avenues when appropriate.

  • Builds relationships with the team and becomes a trusted advisor to them.

  • Coaches the team to become self-organizing.

  • Facilitates meetings and encounters, does not directly tell people what to do, and helps people gradually change their own behavior.

The Scrum Master protects the team from outside interferences by coaching the organization on the benefits of Scrum and Agile principles. Using servant leadership techniques, they remind the organization of the benefits of Scrum when they are tempted to return to old habits.

0 | 1 | 2 | 3 | 4

The diagram below depicts each of the areas covered in this assessment. The Product Owner is the single point of contact for the team on things that relate to the product. The Scrum Master is a servant leader in the process and acts like a flashlight shining light on areas that need attention.

Pict3.png

Each of these items are interrelated, and deficiencies in any one ripple into the others. A sprint should not simply be used as a convenient bucket for work.

Assessment Review

If you have a 0 in any of these areas, your Scrum outcome will be very negatively affected. It is important to elevate each of the 0 areas to some non-zero value as soon as possible. If there are many of them, consider pausing delivery for a short period of time and developing an action plan to improve them. Another area to look at is highly inconsistent rankings, which will result in a skewed score.

There are 11 areas in the self-assessment that are ranked from 0 – 4. It is important to understand that regardless of how your ranking came out, you will improve over time as long as you stick to Scrum principles. Think of it like a diet and exercise plan. You could begin out of shape. Exercise is hard, but over time, you get stronger and more fit.

  • 34 - 44 – your team should be feeling quite accomplished in its adoption of Scrum. Here are some things to look into:

    • Do you have a stable velocity? Look at the velocity of the past five sprints and see if it is consistent.

    • How is the quality of your product? If you have too many defects, you may want to add more unit tests and increase the DevOps approach you are taking.

    • Are your customers happy? If you cannot quantify this, consider sending out some questionnaires and ask customers to rate your product.

  • 23 - 33 – you are probably following the mechanics of Scrum but not the true essence of it. Meet as a team and look at one or two of the lowest ranks. Decide as a team how to specifically improve. Put together a roadmap of how you will improve.

  • 11 - 22 – this score indicates that some real work is needed. Do not be discouraged. It is never too late to start. Have a team meeting and a frank discussion about the issues that resulted in a low score. If you find you do not know where to start, you may want to hire an Agile coach to help guide the team down the correct path.

Learn More About It

Below you will find links to a set of excellent videos about Agile. I highly recommend that you take the time to view them.

  • Product Owner In a Nutshell - This is the best single video I have seen on agile. Its title focuses on the product owner but it really covers all of agile delivery.

A PDF version of this article is available here.