More on this book
Community
Kindle Notes & Highlights
Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products.
The product owner is responsible for maximizing the return the business gets on this investment (ROI).
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 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. While a team’s deliverable is the product, a scrum master’s deliverable is a high-performing, self-organizing team.
The scrum master is the team’s good shepherd, its champion, guardian, facilitator, and scrum expert. 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
High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. The theory is that the people who do the work are the highest authorities on how best to do it. Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.
A scrum team should posess all of the skills required to create a potentially shippable product.
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
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
The sprint backlog is the team’s to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.
A burn down chart shows us what is left to do. In general, we expect the work remaining to go down over time as the team gets things done. Sometimes the work remaining changes suddenly, when scope is added or removed. These events appear as vertical lines on the burn down chart: a vertical line up when we add new work, or down when we remove some work from the plan.
When the team’s tasks are visible to everyone from across the room, you never have to worry that some important piece of work will be forgotten. The simplest task board consists of three columns: to do, doing and done. Tasks move across the board, providing visibility regarding which tasks are done, which are in progress, and which are yet to be started. This visibility helps the team inspect their current situation and adapt as needed. The board also helps stakeholders see the progress that the team is making.
In order to avoid confusion, good scrum teams create their own definition of the word “done” when it is applied to a user story. They decide together what things will be complete before the team declares a story to be done.
Additionally, the more frequently the team delivers and demonstrates a potentially shippable product increment, the more frequently the team gets feedback, which fuels the important inspect-and-adapt cycle. The shorter the sprint cycle, the more frequently the team is delivering value to the business.
Sprint planning marks the beginning of the sprint. Commonly, this meeting has two parts. 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. We recommend one to two hours of sprint planning per week of development.
The product owner leads this part of the meeting.
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.
