Scrum Guide Decomposition, Part 3
The third Scrum Guide breakdown addresses Scrum Events and some of the criticism around certain sections.
Join the DZone community and get the full member experience.Join For Free
This is the third part of the Scrum Deconstruction. You can find part 1 here and part 2 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org's PSM I exam that I took back in October 2017. I have made updates based on the newest version of the Scrum Guide, November 2017. Here I share in the hope that someone finds it useful.
Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore, there may be mistakes.
Sections in Black will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.
Sections in Red will be the negative aspects that I see, or have been told, read, or anything else negative. Sometimes these will sound silly (and probably are) as it I find it difficult to find negative aspects, this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.
Side Notes are in green.
Now, let's get on with the deconstruction.
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Note: It says "minimize the meetings not defined in Scrum," not "exclude them."
All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
If you decide on 2-week sprints, stick to it; if you decide on 1 week, stick to it. Some teams start to try different lengths when they first start. They may try 2 weeks, 1 week, or 3 weeks, but once a decision is made on the sprint length, stick to it. Don't chop and change from sprint to sprint when it is convenient. Make it like clockwork.
I don't work in 2- or 3-week blocks, I just do the work.
That's ok, you don't have to work in sprints — but that then isn't Scrum. See Kanban.
The Sprint gives a regular time everyone knows and can work towards. It will also force you to create something in the end. The pressure (not too much, not too little) can help foster innovation, as you have to produce something.
The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
By fixing the maximum time, you prevent events from taking too long. It prevents them from going forever. It also helps focus the event to get the result. The sprint is different. It generally does not end sooner. For example, when the sprint backlog runs out prematurely. In this instance, you just pick up more work from the Backlog.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.
Look at each event as an opportunity to look back at what you have done and try to improve. Don't just leave it for the retrospective.
These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
Also, too, if you treat the event as a "tick in the box" event, you reduce its effectiveness.
The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done," usable, and potentially releasable product increment is created.
You should create something useful. Not documentation, not a plan, not an environment. It can be small. Only do one specific thing in a narrow field, but make sure that it is usable.
Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous sprint.
There is no "a few days/hours of planning" before the next sprint. Everything is incorporated in the sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
When, with all that stuff, do you actually work?
A Sprint does nothing outside a normal project. It just does it in smaller blocks, rather than planning up front as in Waterfall.
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality goals do not decrease; and, This is important. When companies start Scrum initially, they push to get things done quicker. When this happens, the first thing to go is quality. But saying that, what is quality? You need to seriously look at what quality is and strip out the waste. For example, documentation or having a 100-page spec sheet that no one reads or can understand is not quality. Having a concise document or diagram that everyone understands is. Also have coding standards that are well-documented and are able to be verified. Nothing is based on individual opinions.
- Scope may be clarified and re-negotiated between the Product Owner and Development team as more is learned. Scope is not fixed. It varies as you learn more.
Each Sprint may be considered a project with no more than one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
How many projects just produce documentation or specifications? Each Sprint is a self-contained project. Just smaller. And no, it's not quite like a small Waterfall project; it's so much more.
Sprints are limited to one calendar month. When a Sprint's horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress towards a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.
Canceling A Sprint
A Sprint can be canceled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the Stakeholders, the Development team, or the Scrum Master.
A Sprint would be canceled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if the market or technology conditions change. In general, a Sprint should be canceled if it no longer makes sense given the circumstances. But due to the short duration of Sprints, cancellation rarely makes sense.
Sprints are canceled if a radical change in Goal is required. Something seriously must be wrong if you cannot wait 2 weeks or a month before you chop and change.
When a Sprint is cancelled, any completed and "Done" product backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog items are re-estimated and put back on the product backlog. The work done on them deprecates quickly and must be frequently re-estimated.
Knowledge fades fast. If you are working on something and have to put it aside for a period of time, then come back to it, you need to get re-acquainted with the work. That takes time. The partially done work needs re-estimation because you need to estimate how much "remaining" work needs to be done. Estimation is a tool to help you determine capacity; it is not a goal in itself to "complete" a certain amount of work, but a tool to help you plan how much work you can be done within a Sprint.
Sprint cancellations consume resources, since everyone has to re-group in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
They are a waste.
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
Eight hours!? Seriously. When do you get the work done!
Eight hours is only 1 day. That is 1/20th the time. A small price to pay to know what you are doing during the Sprint.
Sprint Planning answers the following:
- What can be delivered in the increment resulting from the upcoming Sprint?
- How will the work needed to deliver the increment be achieved?
Topic One: What Can Be Done This Sprint?
The development team works to forecast the functionality that will be developed during the Sprint. 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. The entire Scrum team collaborates on understanding the work of the Sprint.
The objective of the Sprint is some functionality that can be used. Something small, but useful. It may be incomplete, but still useful. The Product Owner needs to get what is in their head into the developers' heads with regards to the objective — not the solution. But — the whole Scrum team needs to work to understand.
This is different than standard practice, where a spec is handed over and everyone works to it. Specs can be interpreted differently. The idea here is to remove the different interpretations, remove the ambiguity to the goal.
The input to this meeting is the Product Backlog, the latest product increment, projected capacity of the Development team during the Sprint, and past performance of the Development team.
The number of items selected from the Product Backlog for the Sprint is solely up to the Development team. Only the Development team can asses what it can accomplish over the upcoming Sprint.
The Development team has the right to refuse work. This is hard because most people want to please. The environment must also be safe enough for the Development team to reject work. Therefore, the Scrum Master should back the team and the Product Owner should respect the decision, contrary to current management where you get what you have been given.
This will never work because management pushes.
After the Development team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum team crafts the Sprint Goal.
The whole team crafts the goal
- Dev Team
- Scrum Master
- Product Owner
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.
The Sprint Goal is functionality to be delivered. Eg.
- Blogging product
- Be able to post a blog
- Purchase Order System
- Be able to raise a purchase order
- Make the CEO happy
Topic Two: How will the Chosen Work Get Done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development team decides how it will build this functionality into the "Done" product increment during the Sprint.
The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The second half of the Sprint Planning is determining the Plan to produce a done increment. Remember the backlog items should not be a "solution." They are a required functionality.
The Development team usually starts by designing the system and the work needed to convert the Product Backlog into a Product Increment. Work may be of varying size, or estimated effort.
Note: Estimation of "effort" not time!
However, enough work is planned during the Sprint Planning for the Development team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development team is decomposed by the end of this meeting, often to units of one day or less.
Note: No mention of stories. Stories are not part of Scrum. Scrum does not specify the method used to format items. Work is broken down from large to small. One day or less is not just development, but everything including testing where possible.
The Development team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
Self-organizes. No one, including the Scrum Master, assigns tasks to individuals. The Scrum Master must encourage the team to self-organize.
Without someone directing, how will people know what to do? They will end up doing nothing!
That is why you need motivated people.
The Product Owner can help to clarify the Selected Product Backlog items and make trade-offs.
This is through negotiation. There is a certain amount of capacity that a team can handle. Over extend and something suffers. The goal is that the only thing that suffers is scope.
If the Development team determines it has too much or too little work, it may re-negotiate the selected product backlog items with the Product Owner.
Too little — add more. Too much — remove some.
The Development team may also invite other people to attend in order to provide technical or domain advice.
But these people do not participate.
By the end of the Sprint Planning, the Development team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organized team to accomplish the Sprint Goal and create the anticipated increment.
This is a feedback mechanism to let the Product Owner know the Development team understands the requirements. It also forces the Development team to put a strategy together on how to do the work.
The Sprint Goal give the Development team some flexibility regarding the functionality implemented within the Sprint. The selected product backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development team to work together rather than on separate initiatives.
The Goal could be the problem to be solved. It is basically something larger and more meaningful than just "the work." It also needs to be something that guides the developers' decisions.
Sprint Goals should be S.M.A.R.T. Goals:
As the Development team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different then the Development team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.
The Daily Scrum is a 15-minute time-boxed event for the Development team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
15 minute max — regardless of team size or Sprint size. It is also not a status report.
The Daily Scrum is held at the same time and place every day to reduce complexity.
This is a test question!
During the meeting, the Development team members explain:
- What did I do yesterday that helped the Development team meet the Sprint Goal?
- What will I do today to help the Development team meet the Sprint Goal?
- Do I see any impediments that prevents me or the Development team from meeting the Sprint Goal?
It's stupid to have everyone standing around answering these questions — just do the work!
These questions do not specifically have to be answered on after another. The idea is that the team huddle together and work out what needs to be done to achieve the Sprint Goal. I don't care if you did the Health Check in the morning. I don't care about the BAU work. I only care what helped make progress towards the goal. I don't care if you did the Health Check in the morning. I don't care about the BAU work. I only care what helped make progress towards the goal.
I have heard of a team that uses the Huddle to work out what they are going to do. Then the Scrum Master or Product Owner or Manager comes in and they then do the stand up. The Huddle in this instance would have sufficed. The Scrum Master/Product Owner/Manager do not need to be involved.
Also note, that the Daily Scrum does not need to be done standing. The "Daily Standup" is an expression from Extreme Programming, not Scrum. If you want to do it sitting down, go right ahead, but saying that, by "Standing Up" you are in an uncomfortable position and more likely to have a shorter rather than longer meeting thus keeping within the 15 minute time-box.
The Development team uses the Daily Scrum to inspect progress towards the Sprint Goal, and to inspect how the progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimized the probability that the Development team will meet the Sprint Goal. Every day, the Development team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal, and to create the anticipated Increment at the end of the Sprint. The Development team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adopt, or re plan, the rest of the Sprint work.
This is a formal chance for the Development team to do something if the plan goes haywire. Rather than continue blindly following the plan, do something about it!
Look — Re-assess — Re-plan — Implement.
The Scrum Master ensures that the Development team has the meeting, but the Development team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development team to keep the Daily Scrum within the 15 minute time box.
A test to try to see if the Daily Scrum is a status meeting rather than a planning meeting is to tell the Scrum Master to piss off! But do this after the team is ready and understands what needs to be done. Another test is to see if the Daily Scrum does not happen if the Scrum Master/Manager is not present. If they are not present, then the team does not feel that they need to get together to discuss the situation. Therefore they only see the Daily Scrum as a status update.
A Scrum Master enforces the rule that only the Development team members participate in the Daily Scrum. Daily Scrums improve communication, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the Development teams level of knowledge. This is a key inspect and adapt meeting.
Daily Scrums may not work if everyone is doing their own thing as there is no need for collaboration. For example, team member John is working on Project A. Jane is working on Project B. David is doing BAU work. Simon is working on an internal piece of work etc.
The question is, in this situation, which occurs quite frequently in business, are these people really working as a team?
A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and Stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next thing that could be done to optimize value.This is an informal meeting, not a status meeting, and the presentations of the increment is intended to elicit feedback and foster collaborations.
This is a set time to get feedback from the stakeholders. With traditional development, stakeholders get feedback at the end of the project. This is usually too late for the stakeholders to make changes — at least without significant costs. Therefore, the Sprint Review enforces the Stakeholders to review at regular intervals. It also does not mean that this is the only time that Stakeholders can give feedback. Feedback may be sought at any time. In fact the more frequent the better, but it should be at a frequency not to interfere with the work.
This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time box.
Again, another time-boxed meeting. The Scrum Master is not the one running the show. They are the event planner. They make sure the event takes place. The Scrum Master helps everyone. Team members, product owner, and stakeholders understand the purpose of the event. They may help direct the event, but the content is all Product Owner and Team.
The Sprint Review includes the following elements:
- Attendees include the Scrum Team and Key Stakeholders invited by the Product Owner.
Key Stakeholders should be those who:
- Pay for the work done so they can see where their money is going.
- Those who will use the product because they will have to live with the result and thus should have a say.
- Anyone else directly involved with the product.
You do not want people unrelated coming along like the whole company. You also don't want walk-ins, only those invited by the Product Owner. This is also not a Town Hall, keep the group small and relevant.
- The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done."
Full transparency here. No hiding half-done work by not showing that feature. Show everything. Done is based on the "Definition of Done."
By showing what isn't done, if stakeholders get angry, this will lead to the team "hiding" stuff. Hiding stuff means that the Stakeholders do not see reality and thus cannot make proper decisions. These decisions then affect the Development team, it could be in the form of more work, new work, etc. before previous work is completed. The only way for the Development team to "catch up" is to work longer hours, or produce shoddy work. Neither of which leads to a good outcome.
The Development team discusses what went well during the Sprint, what problems they ran into, and how those problems were solved.
More transparency. This time from the Development team. By going through the development process, the Stakeholders can appreciate the work the Development team went through. It also helps the Development team take pride in their work. Rather than just showing what was done, they share the "struggle" they had to get the Increment done. A Developer that takes pride in their work is more likely to be engaged.
- The Development team demonstrates the work that has been "done" and answers questions about the increment.
Show the Stakeholders the progress and let them see so they can give better feedback. An even better method for the demonstration is to allow the Stakeholders to do the demonstration themselves with guidance from the Development team. Do not try to avoid bugs. Show them so the Stakeholders are aware of them. Use this as an opportunity to find the "faults" rather than just show the progress. By finding the faults, you know where your improvement needs to focus.
This is where the term "showcase" comes from. It becomes a "Show and Tell". A Showcase does not help the product get better which is the goal of the Sprint Review.
- The Product Owner discusses the Product Backlog as it stands. He or She projects likely target and delivery dates based on progress to date (if needed).
This is to give transparency to the Stakeholders so they have a rough guess as to when the product will be finished or the feature they are interested in is finished. Based on the work to date, completion of the Backlog can be determined based on current progress, such as burndown charts. If, for example progress is slow and delivery dates could be missed, the Stakeholders can discuss dropping features that are no longer required. Ultimately, though, the final decision rests with the Product Owner.
Target and Delivery dates should not be arbitrary. For example, set a date to get the team to work faster. This adds stress to the overall process. Leading to teams working late into the night to meet a false deadline only to find out that is made no difference. This becomes very demoralizing for the team. It also shows disrespect for the developers as there is an insinuation that the developers are not working to their best capability.
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
The key here is collaboration. Everyone gets a voice. Everyone has input.
- Review of how the Market Place or Potential use of the Product might have changed, what is the most valuable thing to do next; and
Things can changes; the Stakeholders, Product Owner may reject what has been done. This is always a possibility, not only for new work, but for work already done.
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of functionality or capability of the product.
This may include canning the project/work. If enough value has been reached, then work can stop. This needs to be taken into account.
The result of the Sprint Review is a revised Product Backlog that defines the probably Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
This is a deliverable of the Sprint Review. It is up to the Product Owner now to determine to include the new items and their subsequent priority. This is just one aspect of the Product Backlog. These items may need further grooming by the Product Owner and the Development team. Everything is up for re-ordering, removal or addition. Nothing is fixed. The Plan potentially changes yet again!
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvement to be enacted during the next Sprint.
This is part of the final portion of the Plan -> Do -> Check/Study -> Act cycle. It is a formal time when the team reviews how they have worked. The output should be a plan (or experiment) on a way to improve the current situation. It doesn't have to be a big change, but there should be a change. The requirement for chance is to prevent stagnation.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprint. For shorter Sprints, the event is usually shorter.
Again, timeboxed to a maximum time. Two-week sprints, usually 1½ hours are allocated.
The Scrum Master ensures the event takes place and that attendants understand its purpose.
This is an interesting statement. It means that the Retrospective is for the Team, by the Team. It is not the Scrum Masters role to "Run" the Retrospective. They merely facilitate the Retrospective.
The Scrum Master ensures that the meeting is positive and productive.
Retros are just a waste of time.
If the feeling by the Team as a whole is that the Retrospective is a waste of time — do something about it! Discuss why it is a waste of time and look at ways to improve them. One common mistake is to skip the Retrospective when it is a "waste" of time. This only "hides" the problem, it does not address the problem. Scrum's purpose is to expose problems, in this case, a meeting for improvement that doesn't do anything. It is up to the Team to actively make the meeting useful. Scrum can't fix passivity.
The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum Process.
Interesting note, there is no mention of the 3 questions in a retrospective anymore.
- What went well during the Sprint?
- What didn't go well during the Sprint?
- What needs improving?
While these questions are answered, they are not directly asked. The answers must be encouraged from the team.
What if people have nothing to say? They shouldn't be made to talk.
That is all well and good, but I cannot tell the difference between not having something to say and not saying anything because...
- You are afraid to
- You are intimidated not to say something because the environment isn't safe.
- You think no one cares about your view.
- You're pissed off.
The only way to be sure is the encouragement of participation to bring the issues out in the open and make sure it is safe to do so.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools.
This isn't a time to go through the work output itself, but how the work was done.
- How the team worked together, if well
- Any experiments on how to work, i.e. making work visible, limiting Work In Progress (WIP), working from home, etc.
The Japanese word hansei comes to mind: acknowledge one's mistakes and pledge improvement.
- Identify and order the major items that went well and potential improvements.
What did we do well that we don't want to forget? What did do well that we can exploit to improve other aspects of the process?
- Create a plan for implementing improvements to the way the Scrum Team does its work.
This, I think, is the most overlooked thing with retrospectives. Planning the improvement. If you do not plan to improve, the retrospective becomes useless. It is all well and good pointing out areas that need improvement, but not doing the improvement guarantees failure.
If you do plan, plan it as an experiment. Have a hypothesis, determine the expected result, and actually see if the result is reached. Determine a timeline to review. It could be the next day, week, sprint, month, but you need that review.
The Scrum Master encourages the Scrum Team to improve, within the Scrum Process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.
This gives you permission to make things better. Challenge the status quo and have fun doing it.
This gives permission for those in "death" Scrum to challenge their situation. I know I don't find "Death Marches" fun. Maybe you do?
Change things up to make them enjoyable. If it's not, you are doing Scrum wrong.
During the Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done," if appropriate and not in conflict with Product or Organisation standards.
This is self-inspection of the work process, the Sprint Review covers the improvement of the work output.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that they will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaption to the inspection of the Scrum Team itself.
Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on the Inspection and Adaptation.
I don't like the statement "Improvements may be implemented at any time." This can insinuate that they may be put off due to "other" work and thus never be implemented. I think an additional statement that improvements should be "tested" as soon as possible. I realize that improvements may need to be put off, but adding "as soon as possible" means they should not sit on the Backlog forever. Also, by specifying "tested" acknowledges the fact that improvement may not actually make an improvement. Thus testing, even a small test will help verify this before implementing a large unwieldy improvement.
That was a long section. We’re on the home stretch.
I actually only got this far when I was studying for my PSM certification. I had gone through the Scrum Guide so often, and I decided to wing the test and try. Lo and behold, I passed.
This doesn’t mean I’ll stop here for this decomposition. Part 4, the final part, is on its way.
Let me know if you have found this series useful in the comments.
Published at DZone with permission of Holger Paffrath, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.