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