According to its creators Ken Schwaber and Jeff Sutherland, Scrum is a framework within which people can deal with and solve complex problems while building products in a creative and efficient way, with the greatest value possible.
It isn’t actually a method, because it only specifies what should be done, not how it should be done. For example, there needs to be a moment of planning by the Scrum Team of the next development cycle, but the Guide doesn’t describe how this moment is carried out.
It does talk about artifacts that need to exist, but not exhaustively. Nor is their format established. Scrum will always require adaptation for the organization’s specific contexts.
The three pillars and values
Any adaptation of Scrum must be based on values and the three pillars: Transparency, Inspection, and Adaptation.
Transparency
The process used by the Scrum Team, whose activities and expectations must be visible to all those interested in the Team’s results. Nothing should be swept under the carpet.
Also, it is necessary that all those involved use a common language understood by all so that the communication flows.
Normally this transparency is implemented via the Task Board which the team uses to give visibility to the workflow and items of value being developed.
More mature teams are more transparent. The relationship of trust between them and the other stakeholders has a strong influence on transparency.
If there is a relationship of mistrust or immaturity, there will be plenty of “hidden” work with little visibility.
Furthermore, transparency is related to the roles people perform during the development of the product, results achieved, expectations, collaboration, etc.
Inspection
Work should be inspected frequently. The Scrum Team asks itself whether it is progressing towards the goals and business results. It should also ask itself how to perfect its working method, the team atmosphere, and the quality of the product being delivered. Using Scrum is to constantly question: how can we improve?
Adaptation
If the inspection determines that we’re not progressing to our goals, it’s time to adapt. This adaptation can be motivated by different factors: changes in the market, competition, client needs, business needs, invalidated hypotheses, among many others.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” (The 12 Principles of the Agile Manifesto, 2001)
Scrum Values
There are five Scrum values:
- Commitment to the team, agreements, and the delivery and quality of the product or service.
- Courage to do what needs to be done and take decisions, even difficult ones.
- Focus on the client, business results, and goals.
- Openness to allow people to be transparent and achieve a safe environment for sharing knowledge.
- Respect of people and organizations.
The Scrum Team
Consists of just three roles, as follows: Scrum Master (S.M.), Product Owner (P.O.), and the Development Team.
Scrum Master (S.M.)
The Scrum Master is the team’s facilitator. He constantly seeks to keep Scrum working. He’s a servant leader who helps the Product Owner, the Development Team, and other stakeholders to understand and practice Scrum. He’s the one who helps the Scrum Team to remove impediments and, if necessary, promote organizational changes so the company becomes more effective and efficient.
In the article Scrum Masters: who they are and what they do, Lucas Gomes talks more about this role, while in the article Dysfunctions in the role of Scrum Master, I write about what the Scrum Master should NOT be.
Product Owner (P.O.)
The person who defines the product’s direction. He’s responsible for looking at problems from the point of view of the client and together with the Development Team create solutions to resolve them, as well as bringing the organization business results. He is responsible for prioritizing the next slices of the product to be developed and verifying the impacts caused by deliveries through effectiveness metrics. He is someone with a systemic vision who understands business strategies, the product, clients, competitors, results, etc.
In the article Product Owner: discovering the role of PO, Andressa Chiara writes about other attributes necessary for fulfilling this role.
Development Team
All the people needed in order for an item on the product backlog to become a product increment (more about these artifacts below). It should be multidisciplinary, self-organized, autonomous, self-governed, committed, and tireless in seeking to improve its working process and the results and quality of its deliveries.
Users, clients, management, end consumers, and other stakeholders
These roles are NOT mentioned in the Scrum Guide, but we know they have an influence on the Scrum Team. These people have necessities which our product must meet. They’re the ones consuming what the Team delivers. The value of the delivery depends on their perception of the product. Below, we’ll see that they take part in some events.
The Scrum Cycle
The illustration below shows the Scrum Development Cycle. It contains the roles described above, events, artifacts, and some good practices we use to facilitate the life of the Scrum Team.
Sprint Planning
This is the moment when the Product Owner discusses with the Development Team which backlog items should be developed in the next cycle to build the product.
The Scrum Master facilitates the meeting, ensuring that everyone stays focused and that its goals are met.
Product Backlog (P.B.)
The main input artifact is the Product Backlog. This is the series of all client and business needs which the product has to resolve. The Product Owner keeps valuing and prioritizing this backlog.
Items don’t have the same level of detail. Those on the top of the backlog (greater priority) contain more information about what will be done, the purpose, and who they’ll be delivered to. The greater the priority, the more detail.
Sprint Goal
One of the first things the Scrum Team must do in planning is to define the Sprint Goal. This serves as a guide for choosing items. Examples of goals:
- Make Mother’s Day products available at pilot stores in three locations: Manaus, Fortaleza, Goiânia.
- Provide fast purchase experience at the site.
- Launch life insurance in the cities of SĂŁo Paulo, Curitiba, and Rio de Janeiro.
We can clearly see where we want to get to at the end of the Sprint. Imagine you’re in the team making the Mother’s Day products available.
Would it make any sense to build a backlog item related to Christmas? Or do something to be tested in Bauru?
Sprint Backlog
Once the Sprint Goal has been defined, the Development Team, together with the Product Owner, defines which items will be built in the Sprint.
It’s important that the team’s capacity is respected and that the Scrum Master be present to ensure this. Scrum teams often use Planning Poker in order to define this capacity.
The Development Team can further detail the backlog item and in doing so will “break it up” into the technical tasks necessary for turning it into a product increment.
The Sprint Backlog is the series of Product Backlog items selected for the Sprint, plus the technical tasks.
Sprint
The main event of Scrum, when all the work is carried out. It begins when we start the Sprint Planning and ends after the Retrospective. It is a time-boxed event.
An analogy to help understand a time-box is if we were to put the time in a steel box that cannot expand. Time is like a liquid filling the box.
When the box is full, there’s no more time. No more will fit inside. The is no: “Give me another week and I’ll get it done.”
During the Sprint, items on the Sprint Backlog are built and turned into potentially deliverable product increments.
Potentially deliverable product increment
A long and strange term. Let’s explain it in parts. A product increment is the application of the concept of iterative and incremental development adopted by Agile Methods.
Instead of spending months or years developing a product and delivering everything at the end of the project, in Scrum the product is built in various iterations (i, i+1, i+2…). With each iteration, we increment and perfect the product.
Some examples of increments:
- In software development, increments are software features.
- In the cosmetics industry, increments might be the series of products to be launched in a package. For example, on Mother’s Day. These increments might be lipstick, perfume, body oil. Each is delivered in one cycle and can already be tested by some end consumers before launching the promo.
- In marketing, they are the formats of a product campaign: Social networks campaign, e-mail marketing, telemarketing, promoter, etc.
- For lawyers, the construction of legal items.
- In production engineering, the increment of operation modules.
Potentially deliverable because the increment must be in a state in which it can be used by the consumer. It can’t be the old: It’s ready, just needs testing. Nor is it a prototype that will be discarded. It might be something incomplete, but IT IS A CONSUMABLE PRODUCT/SERVICE.
The delivery for consumption is a business decision and therefore depends on the Product Owner’s decision. This is because the Team might deliver something which, strategically, isn’t desirable to launch on the market.
For example, let’s say the Team is working in October on the site of the Christmas sales. It might call on clients to try the new site and get feedback during the iterations, but it wouldn’t be desirable to launch this site before mid-November.
Definition of Done
To know whether an increment is ready to be delivered to the consumer, we use the Definition of Done, which is all the elements a product must fulfill before being delivered. A sort of check-list.
- Example of Definition of Done in Software Development: code in the repository; passed all continuous integration server tests; packets generated, etc.
- Example in production engineering: robot installed; operation manual updated; safety rules placed in a prominent location, etc.
If the item doesn’t fulfill all the demands of the Definition of Done, it’s not ready and cannot be delivered. In Scrum, there is no ½ ready or 99.99% ready.
Sprint Duration
The duration is fixed and can be from one to up to a maximum of four weeks, preferably as short a time as possible. This period DOESN’T keep varying.
This means that if the Scrum Team decides the Sprint will have a duration of two weeks, all the Sprints will last two weeks.
Can I reduce the size of the Sprint?
Yes. But it must be something everyone is in agreement about, and be for an important reason.
For example, the Scrum Team has automated one part of the process and thinks it’ll be able to do weekly deliveries of value. From now on, all the Sprints will last a week.
Can I increase the size of the Sprint?
Be very careful about doing this. The Team may be simply hiding a problem, instead of solving its root cause.
For example, the team increases the Sprint by a week because the quality of the product is low and the quality people only have a few hours to check the product. Now there’ll be two weeks’ development and one for tests.
To begin with, everyone thinks this has resolved the problem, but it’s not true. So, this team will increase again to four weeks, because in practice the development time will also increase, The root problem which ought to be addressed is the low development quality.
The consequences of increasing the size of the Sprint:
- Avoids addressing the root cause of problems;
- Significantly reduces the capacity for adaptation of both team and the product;
- Reduces the number of tests the Team will carry out;
- Diminished efficiency;
- The delivery of value (effectiveness) also falls;
- The team becomes more subject to external interruptions;
- Reduced amount of feedback about the product;
- Delays continuous improvement;
- And many others.
A simple calculation shows how bad over-long Sprints are:
| Number of weeks in Sprint | Number of Sprints per year |
| 1 | 52 |
| 2 | 26 |
| 3 | 17 |
| 4 | 13 |
See how the greater the Sprint, the fewer experiments we’ll have, making us more susceptible to suffering the consequences listed above.
Daily Meeting
As soon as the Scrum Team defines the Sprint Backlog, the work begins turning the selected items into product increments.
During this period, the Development Team meets daily at the Task Board for the Daily Meeting. This meeting is carried out by the Development Team for the Development Team. The Scrum Master facilitates if necessary and the presence of the Product Owner is not obligatory.
External people (management, stakeholders, the curious) only take part if the Development Team agrees and provided they stay silent throughout the event. We need to create a safe environment of collaboration and not one of presenting a status report and justifications.
This event should last 15 minutes at the most and the goal is to define what the Development Team will do that day to progress towards the Sprint Goal.
It’s a moment for the Team to inspect (will we achieve the Sprint Goal?) and adapt (what can we do to adjust course and achieve the Sprint Goal?).
To support this purpose, the Scrum Guide suggests three questions, but they’re not obligatory:
- What did I do yesterday which helped the Development Team achieve the Sprint goal?
- What will I do today to help the Development Team achieve the Sprint goal?
- Can I see any obstacle which hinders me or the Development Team to achieve the Sprint goal?
Task Board
This is a tool for the Scrum Team’s transparency. It contains all the work the team must do during the Sprint, including activities not related to product development (participation in committees, support for other teams, maintenance of other products, meetings, etc.)
The board can start with the simple format of three stages: things to do, what the Development Team is doing and what it’s already done.
As time goes by, the Board can reflect a more complete workflow.
Monitoring Charts
The Scrum Team can also produce monitoring charts to help easily visualize the evolution of the Sprint or the construction of the whole product.
The most common monitoring charts are the Burn Down Chart, Burn Up Chart, Value Graph, and Cumulative Flow Diagram (CFD).
A frequent question: who is responsible for updating the chart? If it’s relevant to the Development Team, then it should keep it updated.
If it’s a chart used to feed information to other stakeholders, then the updating can be done by the Scrum Master, Product Owner or by the Development Team.
Sprint Review
At the end of the Sprint, the product increment is presented to consumers, users, clients, management, and other stakeholders.
The whole Scrum Team takes part. The primary goal of this event is to get feedback about the product. The book The Mom Test, by Rob Fitzpatrick, has excellent tips on how to ask questions in order to get good feedback.
The feedback given by guests can become new items on the Product Backlog. They may be highly strategic and go to the top of the backlog. Otherwise, they can go in the middle or just at the end. There is also the possibility of discarding feedback if it’s not relevant.
The important thing about this event is that the consumer uses the product. It isn’t a meeting for presenting slides or increments which don’t meet the demands of Definition of Ready.
In this meeting, information can be presented about the project’s progress, but the focus will always be on feedback about the product or service.
Sprint Retrospective
This is the moment for continuous improvement. The whole Scrum Team takes part: Product Owner, Scrum Master, and all the members of the Development Team. The goal is to improve the whole team’s way of working.
It is a safe environment in which the Scrum Team discusses mistakes and weak points. So there should be no people from outside the Scrum Team unless the whole team agrees to invite someone.
Knowledge21 has an e-book about the Retrospective. Download the free e-book about Agile Retrospectives!
Refinement of the Product Backlog
This isn’t an official Scrum event, but it’s good practice. The refinement can be done at any time and we can organize meetings for it.
The goal is to keep the Product Backlog updated and prioritized with input from new ideas, previous results, clients, management, market changes, changes to competition, innovations, etc.
It’s also good that the Development Team takes part in the refinement to estimate the effort or discuss the technical complexity of the priority items.
However, this shouldn’t consume more than 10% of the Development Team’s capacity during the Sprint.
If the refinement hasn’t been done before, it’ll take place during the Sprint Planning. In this case, it’ll be a very long meeting.
Ideally, the Product Backlog will have been updated and valued before the planning event, if possible with the estimated effort.
Definition of Ready
Some teams like to use a minimum definition to guarantee that the item has been refined and can be discussed in the Sprint Planning.
The Definition of Ready is also not officially part of Scrum but does help the team lose less time and be more focused during the planning discussions. Examples might be:
- The item must be written in User Story format;
- The acceptance criteria are defined;
- The metrics for measuring the impact of the item have been selected;
- The business value of the item has been defined;
- The item’s consumers were invited to the Sprint Review;
- The effort to build the item has been estimated.
Conclusion
This article deals with the general aspects of Scrum. I’ve written about official items in the Scrum Guide and good practices that we at Knowledge21 have learned over time.
I hope this text will help you adopt the framework. Feel free to post any doubts in the comments.
I’d like to invite you to find out more about this framework.
If you’d like to become a Scrum Master, come and take part in our Certified Scrum Master (CSM) training.
If you want to become a Product Owner, the Certified Scrum Product Owner (CSPO) and Agile Metrics training are great for understanding the task in hand.
If you’re a member of a Software Development Team, take part in the Certified Scrum Developer (CSD) training.
And if you’re a manager in an organization that is adopting Agile Methods, I highly recommend the Management 3.0 training.
