The Scrum Guide
Traditional project management would have you create a detailed plan of any project you work on before the start of the project. However, at the beginning of a project you know less about the problems you are solving, and as the project progresses you gain a better understanding of these problems. This insight was one of the drivers to the Agile movement and iterative software development.
Scrum is an agile software development process for iteratively managing product development. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. With Scrum, teams deliver early, and then continuously improve and adjust their product in response to changing requirements. This method of development helps the team build a solution that solves the customer’s need rather than just meet the initial requirements.
Here’s an in-depth guide on how to implement Scrum successfully using Sandglaz.
The Scrum Team
A Scrum team is a cross-functional self-directed team: a group of people with varying expertise working together towards a common goal.
Product Owner
The Product Owner represents the customer. She is responsible of making sure that the team delivers value to the business. There can only be one Product Owner in a Scrum team, that person could also be a developer on the team, but may not also be the Scrum Master.
The Product Owner needs strong communication skills, as she represents the stakeholders to the team, and the team to the stakeholders. She understands the customer and business well, and creates tasks for the Product Backlog that deliver to the customer’s needs. She prioritizes and organizes sprint releases and ensures that the Product Backlog is visible, transparent, and clear.
Her responsibilities include negotiating priorities, scope, funding, and schedule, educating stakeholders in the development process, organizing milestones reviews, communicating status, announcing releases, and demonstrating the solution to stakeholders.
Scrum Master
The Scrum Master is the servant-leader of the team. She ensures that all the team’s needs are being met, and removes any distracting influences to help them move at full speed. She enforces the rules of Scrum, and challenges the team to improve. For examples her responsibilities include determining the definition of done for a project, and promoting self-organization within the team.
The Scrum Master is different than a project manager, as Scrum teams are self-organizing teams. In fact in Scrum, there shouldn’t be a project manager on the team.
Development Team
The development teams is a cross-sectional team that does the actual work of delivering a potentially shippable product (PSI) at the end of each sprint. They do the analysis, design, development, tests, QA, documentation and all that is need to deliver the product. The team size ranges from 3 to 9 individuals.
The Scrum Process
The goal in Scrum is to deliver early and often: starting with a minimum product and continuously improving it with customer and stakeholder feedback. This allows the product to evolve with real customers using it and evaluating it, rather than creating an initial list of requirements and sticking to them even if it ends up not meeting the customer’s needs. Moreover, it allows for flexibility to meet changes in the market.
The process of delivering a product in Scrum, is via iterations called sprints. At the end of each sprint, a potentially shippable product is delivered. At the beginning of each sprint, the team decides on the Sprint backlog, a section of the Product Backlog that they will deliver in a sprint. This could be a specific feature for example. This section will need to be completely done by the end of the sprint such that the team is confident enough to release it if need be.
Product Backlog
The Product Backlog is the list of requirements for the product. It contains everything that needs to be done: features, bug fixes, technical work, knowledge acquisition, etc. An example of technical work is ‘install Windows to test on it’, an example of knowledge acquisition is ‘research a javascript library for tag autocomplete functionality’. The product backlog is the responsibility of the Product Owner who maintains it based on his communication with the stakeholders and the team. It is a living document that continuously evolves as new information surfaces about the product and its customers. It is dynamic, visible to everyone, and is the single version of truth.
The Product Backlog is initially drafted by the Product Owner based on her understanding of the requirements, the work involved, and the priorities. Tasks that are to be tackled sooner should be more refined than those that are farther away.
This can be easily done in Sandglaz:
- Start by adding a project
- Set the column duration to match your sprint length. In Scrum a sprint is anywhere between 1 week and 1 month long. Experiment with your team with different Sprint lengths until you find what works for your team.
- Share the backlog with your team. Share as a ‘reader’ to stakeholders, and as an ‘editor’ with the Scrum Master and the Development team. This is important as the team will be self-managing their own tasks: assigning them to themselves, discussing them, creating additional tasks that can come up, etc.
- Start adding tasks directly under each sprint. Don’t worry about scheduling them right (You can easily move them around by drag and drop) . The prioritization of tasks are a guess made by the Product Owner. They are expected to change. For tasks and ideas for much later in the future, just place them directly under “Someday”.Tip: quickly categorize tasks by using typing hashtags in the name (e.g. #bug, #investigate, #backend)
- Tasks can be moved around: from sprint to another, from “Someday” to a specific sprint, and within the same sprint. While the Product Owner prioritizes the tasks, the team decides which tasks will be completed in a sprint and moves them accordingly. They try to select the tasks that can be accomplished in one sprint. Optionally, they can select some lower priority tasks that they will only do if there was time left in the sprint.
The tasks are also not to be assigned to anyone. Each team member is responsible for assigning tasks to themselves.
Backlog refinement meeting
The backlog needs to be constantly updated and refined. Therefore it’s common to hold ongoing backlog refinement meetings, where the team spends their time going through tasks in the backlog to ensure they’re up to date. They would:
- Split coarsely defined tasks into finer grained, well-defined tasks for coming sprints
- Merge tasks for better delivery
- Remove tasks that are no longer needed
- Add new tasks and determine whether they are needed during the upcoming sprint or to be left under “Someday”
- Move tasks between sprints
Sprint
A sprint (or milestone) is a time-boxed effort that ends with an incremental improvement to the product that is completely done: fully integrated, tested, documented and potentially shippable. The team starts each sprint starts with a planning meeting where the team decides on the tasks to be worked on during that sprint. The team ends the sprint with a review meeting and a retrospective meeting. The review meeting is to review the work that was done often demoing the product to stakeholders, while the retrospective meeting is focused on learning from the past sprint to improve the process.
Sprint Backlog
The Sprint Backlog is a part of the backlog that the development team must deliver by the end of the sprint. During a sprint no one can add tasks to the sprint backlog except for the development team themselves.
As the team works on the sprint they assign themselves tasks, and mark them as completed when they are done. They can also create subtasks, discuss tasks with one another, attach files and notes.
Sprint planning meeting
In this meeting the team decides on the work to be done next sprint. This meeting occurs at the beginning of each sprint and is typically 4 hours long for a 2 week sprint or 8 hours long for a one month sprint. During the first half of the meeting, the Product Owner, Scrum Master, and the development team discuss the priorities in the product backlog communicating expected development effort and business value of the tasks. In the second half of the meeting the development team hashes out the work for the next sprint finalizing the sprint backlog.
Daily Scrum meeting
A time-boxed meeting that occurs each day of the sprint. It is sometimes called stand-up meeting, as it is common for the team to stand up during the meeting. It’s 15 minutes long, always happening at the same time and location. The team shouldn’t wait for anyone who is missing. While all are welcome, only the core team members speak. They all come in prepared to give a quick update. Each person says what they worked on yesterday, what they will work on today, and any impediments that they see. Impediments are not to be discussed within the meeting, instead the Scrum Master makes a note of them and works on resolving them outside the meeting.
Sprint review meeting
This meeting occurs at the end of each sprint and is limited to 4 hours. In this meeting the team demos the work to stakeholders. They review the work that was completed as well as that that was planned but not completed. Teams often discover that the final touches take the most effort and time. Partially done work should not be called “done”. Only fully integrated, tested, and potentially shippable work is “done”.
Retrospective meeting
Facilitated by the Scrum Master, this is a 3 hour meeting that occurs at the end of each sprint to reflect on the past sprint. The purpose of this meeting is for improving the process itself. The team discusses what went well during last sprint, what went wrong, and what they can do differently to improve. It is important that everyone gets a chance to air their opinions in an open, honest, and constructive atmosphere. This meeting helps build the team’s sense of ownership and self-management.
Lather, Rinse, Repeat.