Scrum - McMasterAI/wiki GitHub Wiki
Contents
Overview
Scrum is awesome!
What is agile? – a framework to develop code that can account for changes in the project deliverables, team, or anything that may affect development or delivery.
What is scrum? – not a methodology, a set of flexible guidelines. A framework. Focuses on how to make the team the most efficient.
Why use scrum? – focused on people, the better the people work together, the better the work will be. Can account for changes in the project team or project deliverables. It is a team-focused project development methodology.
Scrum Team
Scrum Master
The scrum master is responsible for promoting and supporting scrum within the team. Through this, they help the team become more efficient and knowledgeable. Working with the team, the scrum master can find what makes the team more efficient. The scrum master will organize all meetings, manage the product and sprint backlog, and ensure that the team can deliver their sprint goal.
Development Team
The core of the team. The team is self-organizing, meaning that the team themselves will break down stories and assign stories amongst themselves during sprint planning and retrospective. There are no titles or roles within the team and all work is shared equally.
Product Owner
The owner of the product. Has information about the product and know what they want the result to look like.
Artifacts of Scrum
Product Backlog
The product backlog stores the main features of the product in a list form. These are called Epics. Epics are taken from the product backlog and broken down into stories during sprint planning, which are then inserted into the sprint backlog.
Sprint Backlog
The epics of the product backlog, broken down into stories that can be completed in sprints. Each story contains several key features, the main features being a point value – to determine the effort of the story and a description of the story.
Increment
Each successful sprint will produce an increment. An increment is the state of the product after each sprint.
Scrum Ceremonies
Sprint
A sprint is a fixed time period where the development team works towards a sprint goal and produces a potentially viable product. As a guideline, Mac AI recommends that sprints should be two weeks long. However, the maximum duration for a sprint is up to one month. Throughout the sprint, there are scrum ceremonies that take place to help keep the development team on track. At the beginning of the sprint, a sprint planning is held to allow the development team to choose which stories they would like to work on. The stories that were chosen at the beginning of the sprint should not be changed throughout the sprint. However, there are certain situations where a story needs to be extended into the next sprint, such as if a roadblock was encountered and no progress can be made until a certain condition is met. In most cases, good planning can avoid these situations. Sprints enable the development team to work on the product in small increments and allow the team to track the sprint velocity and adjust the team's progression and workflow as needed.
Key points:
- The duration of the sprint is fixed and should never change.
- Create a sprint goal as a team by assigning stories, and work towards that goal during the sprint.
- At the end of the sprint, the development team will produce a minimum viable product.
- In general, the scope of the sprint should not change, but there are certain situations that should be negotiated with the product owner.
Standup/Scrum
A daily standup, or daily scrum is a ceremony in which the team gets together to update each other on each other's progress on their stories. Each member of the development team should inform the rest of the team of three things:
- What was completed in the time between the last standup and now.
- What you are planning to complete in the time between now and the next standup.
- If there are any problems blocking you from completing your task.
This allows team members to understand what is currently being worked on and if there are any problems encountered by a team member, then the solution may lie with another team member's aid. The attendees of a daily standup are the scrum master and the development team.
Key points:
- The standup should be daily, or as often as teams are able to meet.
- In a standup, each team member states what they have done since the previous standup, what they plan to do until the next standup, and if any problems were encountered.
- Attendees: scrum master, development team
Sprint Planning
The sprint planning is a ceremony which occurs in the middle of a sprint. The goal of the sprint planning is to plan and set a sprint goal for the next sprint. At the sprint planning, the entire scrum team gathers to decide what will be accomplished in the upcoming sprint. This includes the scrum master, the development team, and the product owner. Stories will be selected from the product backlog and moved into the sprint backlog. Once a task is chosen from the product backlog, it needs to be broken down into stories that can be then combed through. The combing process involves the development team assigning points to a story. The guidelines for assigning points are as follows:
- The team will collectively decide on the number of points for a story.
- The points will be selected based on numbers from the Fibonacci scale.
- The stories will be broken down into the smallest workable tasks possible.
- Development team members will choose their own stories to work on.
- For a two-week sprint, max capacity is 8.
The scrum master will work with the development team to break down the item(s) from the product backlog into stories for the sprint backlog with input from the product owner on which tasks are most important. The product backlog items should be broken into small stories that can be completed within a sprint. Points will then be assigned by the development team collectively. The recommended max points per story is 8, however there may be cases where it is more. If possible, break down the story into smaller stories so that the number of points does not exceed 8. If this is not possible, then more people can be assigned to the story so that it may be completed in a single sprint. If changes to the sprint backlog are required based on new insight, then the sprint backlog can be modified at any time during the sprint. If any changes are required for the product based on new/changed requirements from the product owner, then those changes will be made in the product backlog, which can then be pulled into the sprint backlog during a later sprint.
When deciding what work will be completed during the next sprint, the scrum master will list out the stories that the development team has planned, and each member will choose their own stories based on their capacity for the sprint. For example, a two-week sprint should have development team members' sprint capacity at 8 points. This can be composed of a single, or multiple stories.
Key points:
- Sprint planning occurs in the middle of the current sprint.
- Development team members and the scrum master comb through items in the product backlog to create stories for the sprint backlog and assign a point value to them.
- The sprint backlog can be modified at any time.
- Development team members choose what stories they will work on during the next sprint.
- Attendees: scrum master, development team
Sprint Review
The sprint review is where all the development team members can show their work that was completed in the current sprint. This can involve presentations or demos for new features, or just presentations for bug fixes. The idea here is to keep the whole team (including the scrum master, the product owner, and anybody else who would like to join) up to date with what has been completed in the project and the team's velocity.
Key points:
- Each team member will present their stories.
- Keep everybody involved in the product up to date with its progress.
- Attendees: the whole world; anybody can join.
Sprint Retrospective
Look at the past performance of the team in the last sprint.
The sprint retrospective is where any member of the team can voice their concerns with how the development team is managed, or how the project is going. Often, this may include a team building exercise to allow team members to more easily voice their opinion. There are three areas that are important to cover:
- What went well?
- What went poorly?
- What can we do to improve?
With these three topics, the scrum team can cover what things can be done to make the team more efficient and able to deliver more easily!
Additional metrics may be used to see the team's progression. One such example is velocity tracking. This allows the team to see how closely they have followed the sprint capacity in terms of completing stories. Ideally, each member of the development team will deliver their max capacity for the sprint each sprint, but in most cases this is not possible as there could be roadblock or other unpredictable events. Likewise, if the team is consistently overdelivering then the points per story should be reduced as the team may be estimating the effort incorrectly. The action should be taken with underdelivering.
Scrum Workflow for Projects
Starting a Story
You've started a story, great! There are several things that you need to know to be able to work as efficiently with your team as possible. When you start a story, you will be assigned an issue or feature through Zenhub which Mac AI is using for Agile management. When you begin work on this story, you should create a new branch from the current release branch for your story. That's where you'll do all your work for the story. More in depth instructions for all these steps are available in the tech document located here.
Working Through the Story
Working through the story, you just need to be aware of a few things. Keep your code linted so that if other people need to work with it, it's easier to understand because the formatting is the same. There are various linting tools, in the tech doc Mac AI recommends pylint for use with Python. When you have completed a task within the story, you should add and commit your changes to your current story branch. If you have made your branch unable to be used or just want a clean branch, you are able to clean the branch and revert it to the same state as in git. Instructions for doing this are available in the tech doc here.
Wrapping up a Story
At the completion of a story, you will need to do several things:
-
Test your code! The last thing you want to happen is that you and your team do so much hard work and it all breaks because one of your functions doesn't work as expected or there was a bug in your code.
-
Ask for a peer review! If you want to make your code the best it can, then you should ask for multiple opinions on your code. There should be a formal code review process for most companies, but we won't hold you to that at Mac AI. Just send a friendly message to your team member or project manager asking them to have a look at your changes/additions.
- When you think your code is good to go, then your need to merge to the current release branch. This can get a little complicated, so we have a more in-depth explanation for how to do this in the tech doc as mentioned above. Found here.