The Sprint Review is an invaluable session to demo progress, engage stakeholders, and discuss what to do next. However, in my experience mist teams don’t take full advantage of the session.
The Scrum Guide says
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
The Scrum Guide 2020
In other words the review is a chance to take a step back and look at the increments which have been completed during the sprint, consider the product goal, and decide the next short term objective.
This should be done in full view of stakeholders, the more transparency the better because this is how we avoid waste and poor quality.
Sharing work with clients and stakeholders is daunting but it’s far better than building the wrong thing.
Personally I’m always worried when I hear teams ask “Do we have anything to demo?”. This often implies to me that they think of the Sprint Review as a presentation of progress rather than a working and planning session. Furthermore, a scrum team should aim to release at least one increment, no matter how small each and every sprint so keep an eye out for these warning signs.
The Scrum Guide reminds us that:
The Sprint Review should never be considered a gate to releasing value.
The Scrum Guide 2020
It is far better to think of the Sprint Review as an opportunity to recap what has recently been completed (if not deployed) and a chance to engage with stakeholders on what should be done next.
Last week we talked about the Sprint Planning session, today I’m going to move on to one of my favourite scrum events. The Daily Scrum.
The fifteen minutes each day where the team catch up are some of hte most powerful, but also some of the most woefully misunderstood of all the scrum events.
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Scrum Guide 2020
In other words the entire purpose of those 15 minutes is to review the team’s progress against the Sprint Goal and ensure that they are still on track. They should consider progress, any new information they’ve discovered, and any risks they’ve found and discuss if any change of strategy is required to hit the Sprint Goal.
The Daily Scrum is about verifying progress against the Sprint Goal. Photo by cottonbro on Pexels.com
The Scrum Guide also says
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
The Scrum Guide 2020
However, more than in almost any other event I see zombie scrum going on in Daily Scrums. In team after team, company after company I see teams standing up around a screen answering the dreaded three questions “What Did I Do Yesterday?”, “What Am I Doing Today?” and “Do I have any Impedements?” (by the way – 99% of the time people apparently don’t).
While there’s nothing wrong with this approach there’s something seriously amiss if the team do not circle back to address the main point of the meeting. Given the raw data we’ve captured from the team on their progress and their blockers do we still believe we are capable of meeting the Sprint Goal? Has something someone has said put that in jeopardy and what can the team do adapt.
The Daily Scrum is the daily iteration of the inspect and adapt pillars of empiriscm (which only works if there is a feeling of safety in the team which creates transparency). Instead of simply waiting for their turn to write the three questions developers should be listening to each other’s answers and looking for indication that the team may not meet it’s objectives.
Don’t be afraid to mix up the Daily Scrum format, but do be very nervous if you’re not discussing the Sprint Goal in each and every meeting!
Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Scrum Guide 2020
It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?
In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.
This, in my opinion is wrong.
When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.
It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.
Working out what to include, or not include in a sprint is never easy
A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.
It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!
I am currently studying with a view to attempting my PSM-III, if I stand any chance of passing I need to go back to basics to make sure I have a rock solid understanding of the fundamentals. With that in mind for the next few weeks I’m going to go back to core scrum and share my views on some of the fundamentals.
You can’t get a lot more fundamental than the sprint. The scrum guide defines a sprint as
Sprints are the heartbeat of Scrum, where ideas are turned into value.
The Scrum Guide 2020
In scrum we plan work in timeboxes, usually 2-4 weeks. By working to a much shorter planning horizon we can gain a lot of confidence as we go by reviewing progress frequently and adapt as required as the project goes along.
It is not a release schedule!
Many teams I have worked with attempt to set their deployment schedule with their end of sprint. These should be entirely coupled, DevOps has lots of good ideas about how and when to deploy. Deployments should be done as required throughout the sprint.
The sprint is about setting a goal and a timebox to achieve it. By having a consistent length of sprint we can gain confidence in the amount of work which can be delivered by looking at how much has been achieved in previous sprints. This is the purpose of velocity and estimation (a useful tool, if not a scrum process).
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.
The Scrum Guide 2020
In other words the team should focus on the objective of the sprint (the sprint goal) and not get distracted and put it in jeopardy in favour of other work.
Quality should be at least as high at the end of the sprint as it is at the beginning, one or more increments of work should be completed should be produced and all should meet the Definition of Done. If it isn’t “Done” then it shouldn’t be included and may be picked up in the next sprint. Testing phases and hardening sprints are categorically not scrum. Each price of work should be a high quality, done, potentially shippable increment.
Refinement of upcoming work and investigation of planned work continued as time goes on. Remember a sprint goal can be achieved even if the method and approach is refined as the sprint goes on.
So how long should a sprint be? This comes down to the development team in question. Generally a more work can be done in a longer sprint, however there’s more risk that something will arise which would invalidate the sprint goal. For this reason sprints should not be longer than one month.
Finally, if at any point the sprint goal becomes invalid the Product Owner may cancel the sprint. This could be for a number of reasons. The priority of work may have changed dramatically due to customer needs or the discovery of a bug (shorter sprints help prevent the waste of cancellation here). Or, the team may discover as they progress that the goal is impossible or not as valuable as originally believed. We’re in the business of doing effective work. If we discover that work isn’t going to be valuable our job is to avoid waste and move onto something which would be.
There’s probably a lot more I could add but hopefully it’s a good introduction. Do follow along for the rest of the series, next week will be Sprint Planning!
dotdotdev.com 