A simple summary of the scrum method for managing projects and increasing productivity.
A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in.
The product owner is responsible for maximising the return the business gets on this investment.
In scrum, no-one but the product owner is authorized to ask the team to do work or to change the order of backlog items.
The product owner is responsible for recording the requirements, often in the form of user stories (eg, “As a <role>, I want <a feature>, so that I can <accomplish something>”) and adding them to the product backlog.
The Product Owner Role in a Nutshell: holds the vision for the product represents the interests of the business represents the customers owns the product backlog orders (prioritizes) the items in the product backlog creates acceptance criteria for the backlog items is available to answer team members’ questions
The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance.
The scrum master helps the team learn and apply scrum and related agile practices to the team’s best advantage.
The scrum master role in a Nutshell: scrum expert and advisor coach impediment bulldozer facilitator
The theory is that the people who do the work are the highest authorities on how best to do it.
The role of each and every team member is to help the team deliver potentially shippable
product in each sprint.
The Team Member Role in a Nutshell: responsible for completing user stories to incrementally increase the value of the product self-organizes to get all of the necessary work done creates and owns the estimates owns the “ how to do the work” decisions avoids siloed “not my job” thinking
The product backlog is the cumulative list of desired deliverables for the product.
Each item, or story, in the product backlog should include the following information: Which users the story will benefit (who it is for) A brief description of the desired functionality (what needs to be built) The reason that this story is valuable (why we should do it) An estimate as to how much work the story requires to implement Acceptance criteria that will help us know when it has been implemented correctly
Unlike the product backlog, it has a finite life-span: the length of the current sprint.
In general, we expect the work remaining to go down over time as the team gets things done.
The simplest task board consists of three columns: to do, doing and done.
They decide together what things will be complete before the team declares a story to be done.
Is the product potentially shippable?
Does it make business sense to ship what we have at this time?
The team delivers and demonstrates a potentially shippable product increment, the more frequently the team gets feedback.
The goal of the first part is for the team to commit to a set of deliverables for the sprint.
During the second part of the meeting, the team identifies the tasks that must be completed in order to deliver the agreed upon user stories.
The goal of part one of the sprint planning meeting is to emerge with a set of “committed” stories that the whole team believes they can deliver by the end of the sprint.
Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.
In phase two of the sprint planning meeting, the team rolls up its sleeves and begins to decompose the selected stories into tasks.
The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks.
Pointed. Each participant quickly shares: What tasks I’ve completed since the last daily scrum. What tasks I expect to complete by the next daily scrum. What obstacles are slowing me down.
The goal of this meeting is to inspect and adapt the work the team members are doing, in order to successfully complete the stories that the team has committed to deliver.
Note that these are not the stories in the current sprint--those stories are now in the sprint backlog.
In this meeting, the team works with the product owner to: Define and Refine Acceptance Criteria Each user story in the product backlog should include a list of acceptance criteria.
This is also the stakeholders’ opportunity to see how the product has been incrementally improved over the course of the sprint.
This meeting is not a decision-making meeting.
The retrospective, held at the very end of each and every sprint, is dedicated time for the team to focus on what was learned during the sprint, and how that learning can be applied to make some improvement.
It’s about process improvement.
Holding a retrospective is especially important after a sprint is abnormally terminated, as it helps the team learn from the experience.
Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback—from customers, from the team, from the market—and to learn from it.