The key to success in Scrum is understanding the WHY’s that underpin the process. Often when teams start out with Scrum, loads of things make absolutely no sense to them. This is perfectly understandable!
However, over the years I’ve found in many organisations, the WHY’s that are asked of me are often the same. So, I’ve tried to provide a brief explanation of what my answers are to these frequently asked WHY questions:
- WHY do we have a stand up when we talk all the time anyway?
- WHY do we have sprint planning that can take so long?
- WHY do we estimate in points?
- WHY are we encouraged to pair program?
- WHY do we have to go to so many meetings?
- WHY should we have a physical board as well as a digital system?
- WHY should we break stories down into tasks?
- WHY do we have to be disciplined when we are doing fine?
- WHY do we have user stories?
- WHY do we have a retrospective every sprint when nothing much changes anyway?
WHY do we have a stand up when we talk all the time anyway?
Throughout a sprint, the Scrum framework provides ceremonies that are effectively times when the team can ‘inspect and adapt’. We inspect our progress and adapt if we need to change our direction. The stand up is one of those ceremonies, and allows us to all get together at least once a day to discuss progress. Often, even though there is a belief that communications are good, teams don’t talk to each other as much as they should. A lot of useful information comes out at the stand up, and it’s this information that we share that sets us up for the day. By the end of the stand up, each team member will know what everyone else is up to until the next stand up, so they can orient their own activities in sync with the activities of the team.
WHY do we have sprint planning that can take so long?
The sprint planning meeting is the starting blocks for the sprint. It takes a long time because we are working with complex software and a lot needs to be considered. By dismissing the importance of sprint planning a team are inferring that they are not working on a complex system in a complex way.
Without a good start, the team cannot be expected to have a smooth sprint. If sprint planning is poorly executed and corners are cut, often the team find they have to make up for it later within the sprint which contributes to slowing them down and potentially missing the sprint goal. Activities like clarifying requirements, realising too late in the sprint that need more information from an outside source, or realising they have overcommitted due to a lack of understanding of complexity can be avoided by engaging in sprint planning properly.
Spending time at the beginning of the sprint saves time during the sprint. Two heads are better than one, so six or more heads are definitely better than one! Going through sprint planning together gets everyone off to the same start right from the beginning and allows everyone on the team to input their thoughts and concerns when breaking down stories into tasks.
WHY do we estimate in points?
We estimate in points because studies show that people estimate more accurately when asked to consider complexity as opposed to time. Time is unpredictable. A lot of things can happen in a very short space of it. In addition, in order to estimate complexity consistently it is easier to use a scale to compare complexity of work in a relative fashion.
Scrum uses a Fibonacci based scale for complexity estimation: 1, 2, 3, 5, 8, 13, 20, 40
E.g. put very simplistically, Story A is 5 points. Story B is 13 points. Story C is in need of estimation. It is more complex than Story A, but less complex than Story B. Story C is therefore 8 points.
Eventually, as teams become better at Scrum, they perform as a team. This in turn leads to stable velocity, which is a very powerful tool for the business that helps it predict how to estimate how many sprint a team will need to complete a project.
WHY are we encouraged to pair program?
Pair programming is statistically proven to improve quality. It does not slow teams down, in fact there is often an increased velocity as a result of pair programming. When done right, team members talk to each other and work together. They don’t just sit and watch while another does all the thinking and typing. They actively contribute as they discuss as they go. Not checking bugs in means developers do not have to context switch to return to the bug later in the sprint. In addition ‘pair programming’ isn’t limited to dev/dev pairing. It also includes dev/test pairing. This combination is very successful as it brings test into the picture before work is checked in, meaning that less defects are created and found further up the sprint.
Pairing is not mandatory as part of the Scrum Process, but it is considered best practice if the circumstances permit it.
WHY do we have to go to so many meetings?
As part of a Scrum team, your role as technical experts is respected to the point that the business do not want teams to just develop the product in the Construction phase, they want you to take active involvement in the evolution of a product from the beginning. As part of a collaborative organisation, your inputs will shape the product as we go to ensure we deliver the best outcomes for the customer. Therefore, we need to have the meetings we have to make sure that we are all talking to the right people at the right time. In Scrum, we do this via the ceremonies which are all designed for very specific purposes in order to get the right outcomes when they are needed at different points within the sprint, such as:
- Pool and develop ideas
- Plan our approach
- Make decisions
- Create and develop understanding
- Encourage enthusiasm and initiative
- Provide a sense of direction and a common purpose
If we do not have these meetings, we often lose the collaborative element that makes Scrum so successful.
WHY should we have a physical board as well as a digital system?
Often teams do not fully appreciate the benefits of a physical board until they have tried it for a few sprints and have experienced the difference it makes for themselves. The physical board is fundamental in assisting a team to collaborative working, which is a benefit that outweighs the perceived cost of duplication. A physical board provides a physical presence for the team. They can meet at the board to discuss work, have the stand up around it and physically move stickies that represent work from one state to another. If you work in a distributed team, you can set up a rota for an offsite coordinator, where someone is the point of contact for off-site team members to contact in order to update their work on the board for them. The main benefit of a board is visibility. It is very easy to see on a physical board who is doing what at all times. The board can be configured to suit way that best befits to work streams of the team without the need for write permissions what you might get on a digital system. The board is a tool to help the team work better together.
WHY should we break stories down into tasks?
The reason we do this is so that we think more carefully about what is involved in the story. Often it is not realised how complex a story is until they are broken down into tasks at sprint planning. Breaking down a story into tasks allows more than one developer to work on a story at once so that the story can get into test earlier. Obviously this could happen without tasks, but it is more visible who is doing what when tasks are in use.
WHY do we have to be disciplined when we are doing fine?
The question to ask here is, “fine compared to what?”. If a team has nothing to compare their current practices to, then how do they really know how good they are, or even how good they could be? Unfortunately the perception that Agile is a liberal, anything goes collection of frameworks that some teams have been led to believe they are is inaccurate. If anything, they are the opposite. The emphasis on individual responsibility to collaborate and communicate effectively within the teams mean that discipline is even more necessary so that teams understand WHY it is important to adopt ways of working that consider the team over ourselves. Agile adoption is a journey that involves us continually inspecting, adapting, learning and improving. You should want more for our teams than to be just ‘fine’.
WHY do we have user stories?
We write user stories for several reasons.
- They allow the team to understand the context around the requirement. All user stories should be written “as a… <role> I want… <feature/function> so that…<I get this benefit>
- The User Story defines the scope of the work, along with the Acceptance Criteria
- Out of scope stories are more easy to identify than feature lists/functional specs because of their context composure
- They can be epic or granular, but all can be estimated.
WHY do we have a retrospective every sprint when nothing much changes anyway?
If a team thinks that nothing much changes in a sprint, there is something very wrong. It is indicative that the team is not challenging themselves to constantly improve or place themselves outside of their comfort zones. Scrum teams are forever evolving, learning teams. They want to find new and leaner ways of working and embrace the challenge of change.