by Jeffrey Ries
The Scrum team works on an iterative basis which means they deliver products incrementally with the goal of ensuring there are as many opportunities to receive feedback as possible. Each new version is as complete as possible so, at the very least, a version of the project that is usable to some degree is always readily available.
Product owner: The Product Owner is the member of the team who is in charge of ensuring the work of the Development Team is used to its maximum efficiency. What this means is going to vary dramatically based on the industry of the project as well as the individual Product Owner. One thing that will never change, however, is that the Product Owner is the only person who is responsible for managing any product backlog. These tasks can be given to the Development Team but the Product Owner will remain accountable for them. These tasks include things like:
Expressing available items in the Product Backlog in a clear and concise manner
Placing these items in order to ensure they are aligned in such a way that best achieves missions and goals
Work to ensure the backlog is clearly visible to everyone so the next task to be worked on is clear
It is important that the Product Owner is always a single person rather than a group of individuals, though they may work towards the goals of a group if they prefer. Regardless, if the priority of a given item is going to change, the Product Owner needs to give the okay. In order for the Product Owner to ultimately succeed at their task, it is important that it is made clear the entire organization respects their decisions. Likewise, it must be clear that no one else has the power to change what the Development Team is working on or what their current requirements are.
Development Team: The Development Team is made up of those who actually do the work when it comes to creating something that can be labeled as “Done”. This is naturally the end of the current Sprint as it is required to move onto the Sprint Review portion of the process. Only the members of this team are allowed to create the Increment.
The Development Team should be structured in such a way that its members feel empowered to do things like managing their own work and organize as they see fit. The resulting synergy this creates serves to optimize their overall effectiveness and efficiency. Good development teams have the following characteristics:
They have the autonomy to take Backlog items and turn them into Increments that are potentially useable as they deem fit
Development Team members are Development Team members, there is no further designation in the space
Likewise, there are no official sub-teams within the Development Team, they can congregate at will
All accountability is shared throughout the entire team
The size of the Development Team should be small enough that it can pivot as needed, while still being large enough to complete a reasonable amount of work within each Sprint. Generally speaking, if your Development Team doesn’t contain at least three individuals then you will tend to see less interaction overall and thus smaller gains when it comes to productivity. Likewise, smaller teams are more likely to be constrained by the skills they do or do not possess, eventually getting to a point where they can’t actively improve the Increment in question without going outside the team.
On the other hand, anything more than 10 people can make it difficult to coordinate everyone effectively, leading to decreased gains as well. Additionally, they can add so many moving pieces to the puzzle that the empirical process begins to break down. The Scrum Master and the Product Owner are not included in this classification unless they are actively working on the Sprint Backlog as well.
Chapter 2: The Sprint
While the organizational style of Scrum is relatively freeform, it still uses numerous events to help add some regularity to the process and also to minimize the need for extraneous events that are not directly prescribed by Scrum. Any Scrum events are going to be time-boxed by nature which means that each will have a maximum possible duration. The Sprint is the primary event in the Scrum process in that it contains all the other events that may take place during the creation of one iteration of a product. After a sprint has started its duration is set in stone and cannot be changed regardless if it is to lengthen or shorten it.
The events within the Sprint can all be seen as a separate opportunity to either adapt or inspect something. These events are especially designed to enable the level of detailed inspection that allows for true transparency when it comes to critical processes. As such, if any of these events are missed or skipped for any reason the end result is a weakened ability for the Scrum team to inspect the process and adapt it accordingly, leading to an overall reduced level of transparency that will hurt not only the current Sprint but all additional Sprints moving forward that are based on the incomplete data.
The Sprint
The Sprint is a time-box that lasts no more than a month during which the Scrum team will generate a completed product that is potentially releasable but certainly useable in some capacity which is referred to internally as an Increment. Sprints should each have the same duration throughout the development of the product in question. A new Sprint should start as soon as the last one ends. Each Sprint will consist of various segments including Sprint Planning, Development Work, Daily Scrums and the Sprint Retrospective.
During each Sprint, it is vital that there are no changes made to the scope of the product or Increment that would make it impossible to reach the current Sprint Goal. Likewise, quality goals cannot decrease during the Sprint, though the scope can potentially be renegotiated or clarified if the Product Owner and the Development Team decide that earlier projections were incorrect.
Each Sprint can be considered a type of project with a horizon of a maximum of one month. Like projects, Sprints are used to accomplish something specific which means that each Sprint will naturally have a goal when it comes to what is going to be built, what the design is going to be like and a general, flexible, plan that will set the Development Team on the right track. It will also have a clearly defined scope of the work to be done and what the resulting increment will be.
It is important to ensure that the scope of the Sprint doesn’t end up growing so long that you are tempted to expand its length. If the horizon for a specific Sprint grows too long, the scope is likely to change too much and the overall complexity and risk may change it into something else entirely. Sprints are useful because they are predictable and they are predictable because it is possible to ensure adaptation and inspection but most importantly progress towards the goal in a reasonable amount of time. Keeping the Sprint length limited also keeps costs easier to track on a monthly basis.
Sprint cancellation: While a Sprint can’t be extended, there is a possibility that it could be cancelled before the Sprint time-box is naturally finished. However, the only person who has the authority to do so is the Product Owner, though they may listen to anyone else involved in the matter, including the shareholders as well as the Scrum Master and the Development Team.
Generally speaking, the only real reason to cancel a Sprint once it is up and running is if the Sprint Goal becomes obsolete. This might happen if the company changes its goals while the Sprint is in progress, or if the technology conditions or market change overall. Generally speaking, however, a Sprint should only if it no longer makes any sense given the current circumstances. This should rarely occur due to the short amount of time that a Sprint is active for, however, especially as the timeframe is quite short.
If a Sprint is canceled, then the first thing that should happen is that any product backlog items that have been generated are reviewed. If any of the Increments are useable or releasable then the Product Owner will accept it while the incomplete items are returned to the backlog with a new estimate towards their completion. Any work that is not immediately useable often has a short shelf-life and will need to be re-estimated if it will ever be used properly.
It is important to keep in mind that if a Sprint is canceled then all of its consume
d resources are lost because of what is not reusable. What’s more, additional resources are going to be required before anything useful is generated as the Scrum team needs to go back to square one in order to get back to work. As such, the cancellation of a Sprint is often seen as quite traumatic to a team and should be avoided if at all possible.
Planning the Sprint: Any work that is going to be generated during the Sprint should first be discussed during the Sprint Planning portion of Sprint. This plan should be created in a collaborative fashion and include the entirety of the Scrum team. Sprint Planning should be kept to less than eight hours each month, with shorter Sprints having shorter planning periods as well. The Scrum Master is in charge of ensuring that all of the events take place on time and that everyone in attendants is on the same page regarding desired results. The Scrum Master should also be the one in charge of keeping everyone else working within the predetermined time-box.
A quality session of Sprint Planning should answer several questions starting with providing a clear estimation of what can be delivered from the Increment that the Sprint will be creating and how the work that is required be completed. The Development Team is in charge of deciding what types of functionality will be integrated into the next Increment for the upcoming Sprint. Meanwhile, it is the job of the Product Owner to discuss the purpose of the current Sprint Goal and note the items in the backlog that they believe would help to reach it and would, thus, be most effective in helping everyone achieve their goals. Meanwhile, the entirety of the Scrum team should collaborate in the understanding of the work the Sprint is doing.
The real input for this meeting should include the past project history for the Development Team, their capacity, the most recent increment of the product and the available product backlog. The number of items chosen from the backlog for this Sprint is going to be up to the Development Team as they are the only ones that can accurately determine what they are going to accomplish during the Sprint.
During this period is also when the Scrum team as a whole creates the goal for the next Sprint. This goal should be the main objective that will be met during the Sprint based on the items chosen from the backlog and should serve to guide the Development team throughout the process of building the next increment.
When it comes to determining exactly how the work in question is going to be completed, the Development team determines this aspect of the process after the Sprint Goal has been created and the next round of backlog items has been chosen. The Development team has complete control when it comes to determining how best to add the chosen functionality to the next Increment. This work will naturally require varying levels of effort and work from smaller groups within the Development team of various sizes.
While this outline doesn’t need to be exactingly precise, it does need to be formalized enough to determine the scope of what can be completed during the next Sprint. Additionally, this meeting should break down exactly what needs to be done for the early days of the Sprint, generally broken into units of a single day. This plan should then be presented to the Product Owner who may be needed to help clarify specifics regarding backlog items and offer up trade-offs that can be made if the Development Team has too little or too much to do for the next Sprint. Other team member or stakeholders may be invited to this portion of the meeting with the Development Team go-ahead as well.
By the end of the planning portion of the Sprint, the Development Team should be able to concisely explain how the work will be completed during the Sprint to reach the target goals in questions. If there is any uncertainty regarding this fact then this is where it will be hashed out as after this the Sprint shifts into high gear.
Sprint Goal: The guiding principal behind the Sprint Goal is that it provides clear guidance to the Development Team when it comes to creating the best increment possible. A good Sprint goal is one that provides the Development team with a fair amount of flexibility when it comes to the functionality that is ultimately created during the Sprint. Any backlog items that are chosen should all work to deliver on a single element of the products function, which is often reflected in the goal for the specific Sprint as well. It can also be any other type of coherence that serves to keep the Development Team working together towards a common goal as opposed to splintering into numerous smaller, more personal, goals.
While the Development Team is in the midst of a Sprint, it should also keep the Sprint Goal and what is required in order to see it completed successfully in mind. If during the Sprint, the work takes an unexpected turn it is then the responsibility of the Development Team to speak to the Product Owner to ensure that the Sprint can proceed successfully.
Daily Scrum: The Daily Scrum is a 15-minute event that should have its own time-box during which the Development Team can discuss what they will be working on between now and the next Daily Scrum. This will make it possible to optimize the team as effectively as possible for the work that is to come, while also providing a clear path for everyone to follow to keep everyone working towards the same vision. The Daily Scrum should be held at the exact same time every day if at all possible to allow it to be the cornerstone of the Development Team’s workday.
Daily Scrums are vital when it comes to ensuring open communication between the Development Team, often to the point that they remove the need for other meetings entirely, thus naturally increasing productivity as a result. They also make it possible for the entire team to be aware of any impediments to the Sprint as quickly as possible. Their daily nature also ensures the team has the ability to make decisions quickly while improving their knowledge at the same time. As such, it is a key component when it comes to the Sprint’s ability to improve thanks to adaptation and inspection.
The Development Team should use the Daily Scrum as an opportunity to inspect the progress that has been made towards the Sprint Goal already and what is going to be done next as well. The Daily Scrum is exceedingly useful as it gives the entire team a place to discuss issues that might make it difficult for the Sprint to be completed on schedule. With the whole team aware of the problem, solving it becomes far more manageable, and will take much less time than would otherwise be the case. It also gives the team an opportunity to reorganize as needed to ensure peak efficiency is ensured and reconfirmed each and every day.
The structure of this meeting should be as fluid as the Development Team itself, and the most important thing is that the end result is effective for those who are using it. Some Development Teams start off each meeting with a list of questions to be answered about the current and future state of the Increment while others are more discussion based. Again, the format that your Development Team chooses isn’t nearly as important as the fact that it works for them.
The job of the Scrum Master, in this instance, is to ensure that the Development Team holds their meeting, while at the same time not trying to direct the Daily Scrum itself. It is also the Scrum Master’s job to ensure the Daily Scrum doesn’t exceed its designated time box. Finally, as this is an internal meeting for the Development Team, the Scrum Master should also work to ensure that other team members don’t disrupt the meeting.
Chapter 3: Looking Back on a Sprint and Planning for the Future
Sprint review: The Sprint Review is held at the conclusion of each Sprint as a means for the entire Scrum Team and any relevant stakeholders to take a look at the new Increment together for the purposes of determining what changes, if any, need to be made to the new Product Backlog. Throughout the Sprint Review process, the team should discuss how the entire Sprint proceeded, and what can be done to further optimize value in the future.
Nevertheless, this is not a status meeting, it is more informal than that with the presentation of the Increment serving as a means of fostering collaboration and eliciting quality feedback. Assuming the Sprint lasted a full month, the meeting should be no longer than four hours. The Scrum Master is the one in charge of ensuring that this event takes place and that everyone involves correctly unders
tands its purpose. They should also be in charge of keeping the meeting to a reasonable length in proportion to the length of the Sprint.
Every Sprint Review needs to include numerous elements, starting with the attendance; the review should include the Scrum Master, the Product Owner, the Development Team and any stakeholders the Product Owner deems fit. The review should then start with the Product Owner discussing what items have been checked off the product backlog with this iteration and what still needs to be completed before everything is said and done.
From there, the Development Team should discuss everything that went well throughout the Sprint as well as the problems that they face and how they overcome them. They will also demonstrate anything new that the iteration can do as a result of the Sprint and answer any questions from the wider team about this specific Increment.