The focus of the sprint review is the product the team is building. My intent here is to help the ScrumMaster and the entire organisation understand that the direct attention and feedback of a broad constituency of the organisation is crucial to maximising the value the team will deliver in succeeding sprints. Sprint reviews have many possible outcomes including cessation of the project.
In most instances, the team is authorised to continue for another sprint and a goal for this next sprint is set. It follows immediately after the sprint review. It is never omitted! Whereas the sprint review is focussed on the product, the retrospective is focussed on the process—the way in which the Scrum team is working together, including their technical skills and the software development practices and tools they are using. And whereas the sprint review is open to the world, the sprint retrospective is restricted to the members of the Scrum team—that is the Product Owner, development team members and ScrumMaster.
This rule is to be understood in the context of the goal of the meeting, which is to inspect at a deep level how the team is collaborating and performing and to take action to improve. This often requires deep introspection and sharing, which in turn requires a safe and secure environment. Boris Gloger [Gloger ] offers a simple pattern called Heartbeat Retrospectives for new teams to learn to hold valuable retrospectives. Esther Derby and Diana Larsen [Derby and Larsen ] provide helpful activities for facilitators of Scrum retrospective meetings.
During every sprint, the product owner convenes one or two meetings where the Scrum Team and, if required, other stakeholders, meet to size backlog items that have been added or re-size large items that need to be split into smaller ones for tackling in the next sprint or two.
The estimation meeting described above is an example. Other examples are story-writing and release planning workshops. This is important to avoid a stop-start effect at the boundary of every sprint.
I coach teams to produce only those artefacts that are really valuable to themselves and to others in the future. This cuts out worthless work and unnecessary killing of forests! Product Backlog The product backlog is simply a list of work items that need to be done over time. Items may be added to the backlog by anyone, but only the Product Owner has the right to determine the order in which they will be executed by the team.
Of course a good Product Owner will negotiate this with stakeholders and the team. Requirements are emergent, meaning we do not and cannot know up front every detail about what we want in a product. Therefore the Product Backlog is a living document and requires constant grooming to keep it current and useful. Many new items will be added over time; existing items are disaggregated to multiple, smaller items; some items may be removed on realising that a desired feature is no longer needed.
Moreover, items need to be sized in order to determine the likely relationship between value, time and cost. And, of course, the order of items in the backlog will change as the relative value between them is seen differently today from yesterday. The stories are commonly written from the perspective of a user of the product.
Sprint Backlog Most teams will know the sprint backlog as the task board, which is the physical representation of the list of work they have committed to do during the current sprint. The task board is an example of a kanban, a Japanese word meaning sign or visible signal. It tells the whole team and anyone else what work they have planned or the sprint and their current status. The classic format requires teams to estimate the duration of each task in hours and on a daily basis to chart the total remaining hours for all uncompleted tasks.
I coach teams to burn down their sprint in story points. So in my coaching world the sprint burndown is just like the product or release burndown, except the the X-axis scale is days rather than sprints. Because features vary in complexity, and therefore effort and time, we use a scale to compare their size.
The most common scale is known as story points. Product Owners then use this velocity to predict the rate at which the team will deliver features in the future, leading to credible release plans.
I coach teams to use an alternative form of the product burndown chart that simultaneously allows Product Owners to track changes to the product backlog. This is essential, given the dynamic nature of this list. Using this chart Product Owners are able to report progress, determine release dates and predict release scope.
Product Burndown Chart Impediment Backlog The impediment backlog is simply the current list of things that are preventing the team from progressing or improving.
These are things the ScrumMaster must bulldoze out of the way in her never-ending quest to help the team be the best they can. OK, perhaps not the CEO. I interpret this to say that there is no tailoring of the process needed in order to start.
The best thing you can do is hire an experienced coach. Failing that, you can try using a pattern that has worked for me with dozens of teams. Obviously I hope you need a Scrum team. Then follow this sequence of steps, which will be detailed in the next pages. Train the Scrum Team in the basics of Scrum 2. Establish the vision 3. Write user stories to form the product backlog 4. Order the backlog items by business value 5. Size the backlog items 6. Re-order the backlog, as necessary, by additional factors 7.
Create the initial release plan 8. Start sprinting! Steps 2 to 7 can be completed comfortably in a two-day product workshop attended by the entire Scrum Team. The best workshops are attended by additional stakeholders like enterprise architects, managers and business people. The Product Owner will usually share his or her vision for the product. One technique I use is to get each member to write his or her personal version of the vision.
Then members pair up and work to create a single shared vision statement from their initial efforts. The process of pairing up continues until the entire team collaborates to formulate a single statement. This exercise utilises the power of the group and results in greater commitment to the resulting vision. The team will display the vision prominently in their work space.
The visioning exercise may take one to three hours. Creating the Product Backlog The next stage is to hold a story-writing workshop. It is advantageous to involve business stakeholders here.
Certainly the whole Scrum Team is involved. Of course, the ScrumMaster or coach facilitates. If you like to join now all you have to do now is provide your credentials via this Google form , and I will sign you up. The Scrum Guide Download the Scrum Guide Reordered for Free. X Login. Email address. Not Registered? If you don't already have a Scrum. Register Here. Back to Blog Listing Prev Next.
November 18, Like Print Bookmarks. Free download. Table of Contents What is Scrum? Related Editorial. Kado Masanori translator website link. Anara Asylbekova translator website link. Korean November Latvian November Andris Savickis translator website link.
Lithuanian November Macedonian November Marathi November Norwegian November Benjamin Sommer and Geir Amsjo translator website link. Persian November Iran Agile Community translator website link. Polish November Tomasz Wlodarek translator website link.
Portuguese Brazilian November Portuguese European November Romanian November Dan Roman translator website link. Russian November Serbian November
0コメント