Next up in the Scrum Guide 2020 series is “The Sprint”. Since we are talking about Scrum again, I will refrain from using the word “iteration” when referring to the “Sprint”.
Scrum Guide 2020
“Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.”
- This does not mean that all teams need to work on the same 1,2,3, or 4 week cadence.
- This does not state that 2 weeks is the standard. It isn’t.
- This specifically states “One month or less to create consistency”.
I have mentioned in previous articles that I have an issue with “A new Sprint starts immediately after the conclusion of the previous Sprint.” My main reason for this is you can not “Sprint” indefinitely. You won’t survive. You need slack time. But the wording is what bothers me. Teams find ways for slack time in their Sprints for learning or just catching their breath as to be able to continue Sprinting. Again I refer to the option of after so many Sprints, taking a week off from Sprinting to do whatever you would like. Learn something new or build something you want too. Henrik Kniberg had a great example of a hackathon week where people would build whatever they wanted too. Whether it had to do with the product they worked on or not. But the thing had to be done by the end of that week, and you had to show it the rest of the team during some kind of a fun party. I like that idea.
“All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.”
Pretty straight forward here. Remember, this is talking about the active Sprint goal. Which is really where our focus needs to be.
Scrum Guide 2020
“During the Sprint:
● No changes are made that would endanger the Sprint Goal;
● Quality does not decrease;
● The Product Backlog is refined as needed; and,
● Scope may be clarified and renegotiated with the Product Owner as more is learned.”
– “No changes are made that would endanger the Sprint Goal;” Does not mean that items in the Sprint are locked requirements. It just states the we can’t make changes that negatively impact the Sprint Goal. But what if we learn that the Sprint goal isn’t valuable or that we should just kill it?
– “Quality does not decrease;” We do not cut corners to get something done due to the time-box of the Sprint. Which by the way, make no mistake about it, the time-box is a deadline to complete the work you committed too. And therefor, the sprint itself is an estimate.
– “The Product Backlog is refined as needed;” The Product Backlog can be refined whenever during a Sprint. There is a flow to this that teams need to figure out how often and whom needs to be involved during Product Backlog refinement. There are many methods to this. One of my favorites right now is Dual-Track Development. Honestly, I prefer to look at a backlog only when I am trying to figure out what to throw away.
– “Scope may be clarified and renegotiated with the Product Owner as more is learned.” Guess what this says, Product Owners have a right to see product as it is being built, and make adjustments as needed to better suite the Sprint Goal. The balance is that the changes can not be so drastic or late that it negatively impacts the Sprint Goal. We can adjust what is needed in any story at any time. The pain from this comes from the that deadline, I mean time-box of the sprint.
Scrum Guide 2020
“Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.”
– This is really just saying keep your planning and building cycles short. Don’t plan for more than a months worth of deliverables as it increases complexity and risk. And it even provides a bridge of thought towards the project minded to say “Each Sprint may be considered a short project.”
Now I don’t really like to think of each Sprint as its own project, but again this goes to my thoughts of the further divide between Agile and Scrum as Scrum starts to become more of a Project Management Framework than a Software Development tool.
But I do like that it is stating not to worry about things more than a month out since too much will change in that time frame and any effort spent now talking about things greater than a month away is waste as it will either not be done, dropped from priority, or change. So refining an item today that you do not plan on building over the next month is waste. I go further than this and say don’t waste time refining anything that you aren’t working on in the next Sprint at the furthest. Don’e even bother to think about the next thing until you are done the current thing. But we are talking about Scrum, and more and more as I go through this it is becoming more obvious the lack of the word “agile”. “Agile” appears exactly zero times in the Scrum guide… This can’t be an oversight at this point.
Scrum Guide 2020
“Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.”
– Stop caring about the metrics that don’t matter in an attempt to manage the team. People can argue that these tools offer the ability for a team to forecast but they are often used as a tool to make demands on the team.
If you are going to use burn-ups, burn-downs, or cumulative flows, keep them visual to the team only as management in most organizations tend to use these in unintended ways. A team may use a burn-up/down to have a honest view of how they are trending towards their Sprint Goal. The cumulative flow a team can use to forecast when they would be done a certain amount of items.
Velocity is another metric that relates tightly here and is often used as a weapon against teams. Whenever you track Velocity you run the risk of someone using that as a means to drive a team. Things like “This team needs to improve its velocity” or “How come this teams velocity is not as good as that teams velocity, this team must be slacking off” are actively destructive statements. Teams have different velocities for various reasons, even velocity changes within the same team happen sometimes drastically. Maybe the team lost some members and are carrying the work load, or bringing new members up to speed. Or maybe the domain of work the team is focused on is more complex and difficult then it was before.
Scrum Guide 2020
“A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.”
– Don’t cancel Sprints because you don’t like how it is going or because you suddenly feel like something else is more important. Context switching is a burden, and unless it is a life or death scenario for the business, it is better to complete the current Sprint and take whatever that new priority goal is into the next Sprint. But it is key to remember that the Product Owner is the only one, in Scrum who can cancel a Sprint.
The Sprint time-box causes problems for new and existing teams utilizing Scrum. And the key that I have found to be most beneficial is to keep the work items small. Typically 2-3 days at most to get to production type of size eases this burden of the time box in most cases.
The other pain of the Sprint time-box is what happens at the end of a Sprint when one item needs just one more days worth of work to get done and teams want to split it out to get partial credit and re-estimate the leftover work. Please don’t do this, the pain is not worth it, and if there is a logical place to narrow the scope of the work item, then that is a learning moment to try and do that from the start.
Always welcoming others experiences and thoughts on the Sprint portion of Scrum. More on this series of posts to come.