More on this book
Community
Kindle Notes & Highlights
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
Each of these users stories, when completed, will incrementally increase in the value of the product. For this reason, we often say that each time a user story is done we have a new product increment.
scrum master’s deliverable is a high-performing, self-organizing team.
The role of each and every team member is to help the team deliver potentially shippable product in each sprint.
Other times, however, the team will need them to work outside their area of specialty in order to best move backlog items (aka user stories) from “in progress” to “done.”
What we are describing is a mindset change from “doing my job” to “doing the job.” It is also a change in focus from “what we are doing” (work) to what is getting done (results).
Stories further down in the list can be larger and less well understood, as it will be some time before the team works on them.
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.
A burn chart shows us the relationship between time and scope.
A programmer might call something done when the code has been written. The tester might think that done means that all of the tests have passed. The operations person might think that done means it’s been loaded onto the production servers. A business person may think that done means we can now sell it to customers, and it’s ready for them to use.
When the team thinks a story is done, they all gather around and review each item, to confirm that it has been completed. Only then will the team declare the story as done.
Notice that there are 2 separate decisions here: Is the product potentially shippable? That is to say, is the quality high enough that the business could ship it? Are all of the current stories done? This is a decision for the team. Does it make business sense to ship what we have at this time? Is there enough incremental value present to take the current product to market? This is a decision for the business.
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.
The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks.
The product owner also commits to being available to answer questions about the stories, negotiate their scope, and provide product guidance until the stories are acceptable and can be considered done.
This means that the team needn’t solve problems in the meeting: simply surfacing the issues and deciding which team members will address them is usually sufficient.
This implies that we need to break the big stories into smaller stories as they make their way up the list. While the product owner may do much of this work on their own, story time is their chance to get help from the whole team.
Unlike the traditional “post mortem,” the aim of a retrospective is never to generate a long laundry list of things that went well and things that went wrong, but to identify no more than one or two strategic changes to make in the next sprint. It’s about process improvement.
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. What you learn while doing the work in one cycle informs your planning for the next cycle.
