There are many different tools and techniques that can be used in Scrum — but not all teams should consider all tools all the time in order to practice Scrum in a meaningful way.
By Bia Dimovski
I've been asked this question many times: How much should we consider when practicing Scrum? How much planning, reporting, and involvement should there be in order to use the Scrum framework as intended? For this reason, here is a quick guide to how much product teams really need to consider to meaningfully apply the Scrum framework.
How Much Planning is Needed in Scrum?
Product teams in Scrum plan just enough to give them clear understanding of what the focus should be for the upcoming sprint. I have seen teams attempt to plan upward of three sprints ahead only to find out they have to pivot based on new knowledge, impediments/blockers they face during the current sprint, external dependencies, etc.
Planning more than one sprint ahead on a product team is usually the result of someone on the team being in an accelerated role — a resource added to the Scrum team temporarily to assist with product domain knowledge. However, instead of assisting, this resource inadvertently steps into the role of a product owner and uses the backlog as a giant reporting tool for micromanaging the team. This of course, is usually driven by the type of leadership primarily focusing on deadlines (discussed in this previous blog post), instead of customer value.
What If Scenario: A product owner new to Scrum, with the assistance of the person in the accelerated role, sets stories for three sprints ahead. During sprint planning, the team is made aware of what they are expected to get done within each of the three sprints so the dev team can plan their work accordingly. The team starts the work in the first sprint and finds out one story is actually not what was originally thought of, as new knowledge was brought in; a good portion of the work in two other stories has external dependencies with known communication delays; and mid-sprint one of the dev team members got sick and had to be out for two days. This affects the sprint in a pretty significant way. It requires the upcoming sprints to be drastically modified.
Because the stories in the upcoming sprint were planned for too far in the future (for a product team), there wasn't enough knowledge about the work, making it hard to for the team to be accurate in their planning. The time the team spent on trying to predict the future through assumptions was unnecessary and would have been better spent on developing the work in their current sprint.
Approach: The idea that product teams need to plan a few sprints out is false. The argument that by having set sprints in advance will help teams pull work from the next sprint up as they get work done in their current sprint, is also false. Having a prioritized backlog will take care of that and save dev teams time and stress in attempting to predict the future. If you observe something like this in your organization, the most optimal approach is to simply open it up for discussion and try to gradually shift to planning for your next sprint only.
Start by first planning for no more than two sprints – one being the current sprint, and the other the next sprint up. No more than that! Then move to planning for the next sprint up only where you are pulling stories from a well-organized and prioritized product backlog. Why? Because that's all you need. The only reason Scrum teams plan for more than a sprint is because of the pressure leadership puts on managers and product owners to meet some arbitrary deadline. It only causes the team stress which leads to rushed work greatly increasing the chances for defects later on.
How Much Needs to be Reported in Scrum
What to Report
There are different ways to report work progress, but the backlog is always the main source. What needs highlighting on the topic of reporting in Scrum is the purpose a specific report serves and how that purpose links to adding customer value.
Ask yourself: Can this report be linked to a customer value? If yes, then discuss it. If no, then find something better to do.
Let's look at a few reporting tools product teams can use in Scrum and the purpose behind each.
The Product Backlog — A repository of all the requirements for the product being developed. It lists and describes the product requirements, including communication among the team members, product owner, and other stakeholders. The reason the product backlog is the main source of reporting in Scrum is because the product owner prioritizes the product backlog regularly so whoever needs to view it will be viewing the most recent progress. There’s no need for a designated person to update status reports in excel spreadsheets weekly or biweekly or monthly, etc. The product backlog is the closest thing to real-time updates.
The Sprint Backlog — If the product backlog is the closest thing to real-time updates, the sprint backlog, as a subset of the product backlog, is the absolute real-time update for anyone within the organization interested in viewing product work progress. It literally contains information on what the dev team is working on today.
Sprint Velocity — A calculation of all the story points the team completed during the sprint. It is mostly used at the end of the sprint to help teams better understand how much work they can complete within a sprint. This allows them to improve their planning for each upcoming sprint. The purpose of this report is primarily and arguably only to help teams learn more about how they work together and what and how to improve/maintain their velocity sprint after sprint.
Burn-up/Burn-down Chart — These charts are a good visual representation of the team's work progress in terms of how far or how close the work is getting to completion. Work completion is not to be mistaken with project deadline, and these reports are not to be linked to such deadline. It is a helpful tool because just like the product backlog it includes all product features and functionalities (not only those for the current sprint) giving a good overview of work progress.
Changes Report — This report serves more as documentation of all the features that were added, modified, deleted, or canceled. It can also include any defects and fixes. This report serves the purpose of storing data for future reference and product work overview.
What Not to Report
Don’t report on status to meet a deadline. Scrum cannot and does not report with the purpose to show how many items were completed in how many hours by how many people. In Scrum, reports and reporting serve to show progress and to learn the general pace of each team within the organization so leadership can have a better understanding as to how quickly value is added to customers. But that shouldn’t be confused with or manipulated into constant status reporting on how many hours a person is head-down cramming work or requesting from teams to break down every working hour to predict when a product will be done. Because if your team(s) is building a product, guess what? They're never really done adding value to customers because customers’ needs change — in fact, you can count on that being the only constant in your product development. 🙂
How Much Involvement is Needed in Scrum?
Team and leadership involvement in Scrum is perhaps the one ingredient of the three needed most. It's a key ingredient, yet so often I observe it being overlooked. Involvement is overlooked mostly because the assumption is that it's understood and expected when it's not.
What drives teams to successfully apply the Scrum framework in developing a product is their active involvement with the work — not just checking things off the plate. This is directly related to the leadership’s readiness and ability to respect the Scrum framework and enable team(s) ownership of the product they are developing. A good way to go about this is to simply ask teams what kind of support they need from leadership. On a grander scale, this also prevents organizations from accidentally sabotaging their own IT initiatives (a colleague at BreakFree Solutions talks about sabotaging IT initiatives in a previous blog).
Understanding involvement in Scrum is crucial because of the level of change present in complex engagements and initiatives within the organization. In fact, before even starting to apply the Scrum framework (if that is the right framework for your organization's business needs), organizations can work with Agile and Scrum experts to understand and define involvement in order to close the gap between team(s) and leadership and pave the road for forming cross-functional and high-performing teams. This will look and feel different for different organizations, but here are a few constants to keep in mind:
Direct and timely communication
No chain of command/middleman involvement
Teams make decisions directly related to the work they develop
Leadership asks teams questions related to the work to gain better understanding for the product they envision and by extension provide the teams with clear requirements
Scenario: Your organization recognizes Scrum is the right agile framework to apply to an IT initiative you are a part of. A couple of teams are given the green light to start using Scrum to see if it works better than the way they are currently operating. The selected teams begin applying Scrum principles and begin to understand the benefits of using the Scrum framework.
Shortly after, they begin experiencing blockers and impediments that reveal other inconsistencies organization-wide, such as delays in communication, unclear requirements, etc. As these impediments travel within the organization the teams are met with pushbacks, while leadership assumes Scrum doesn't work.
Approach: If this sounds familiar to you within your organization, then you know you have a Scrum involvement deficiency. It's time to have a daring conversation with leadership to initiate a push pause approach and define involvement.
Deciding if the Scrum framework is the answer to your organization's business needs and knowing how much your organization needs to consider when using Scrum can be a rather daunting task.
Our members at BreakFree Solutions work with organizations to initiate this type of change in the most productive and effective way based on the specific business needs of the organization. If that's you, do not hesitate to reach out. We love what we do and when you are ready, we are happy to have that conversation with you.