As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product. Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests. Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders. One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team. Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum. What if my Product Backlog is not easily visible to every stakeholder? Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work. If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.
The Product Backlog is a list of potential work to be done for future Sprints. This list is most vibrant when as many people as possible contribute to it. Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value. Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome. Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision). If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost. Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.
Product Backlog Items closest to the top of the Product Backlog should be small enough for the team to be able to complete at least one potentially shippable slice of the product in the next Sprint. As well, they should be ready for the Sprint Planning meeting so that the team can plan its work for the Sprint. To be ready for the Sprint Planning Meeting, each PBI must be estimated. Generally speaking, Product Backlog Items at the top of the Product Backlog are clearer and more detailed than lower ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that at least one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting. Having too many items in the Product Backlog “ready” for the team is considered wasteful over-planning, although generally the top ten items should be in this “ready” state. The value of having a refined Product Backlog before the Spring Planning Meeting is that it enables the Scrum team to focus on the purpose of the Sprint Planning Meeting which is to answer these questions: What will be delivered in the Increment resulting from the upcoming Sprint and how will the work needed to deliver the Increment be achieved? Essentially, what is the Spring goal and what are the tasks needed to complete the goal? Without a ready Product Backlog, the purpose of the Sprint Planning Meeting is difficult to achieve.
One of the key benefits of the using Scrum is that it allows the team to quickly identify defects and obstacles. Now that the team has made these known, the team has the ability to remove and fix these defects. What is the value of identifying problems in the product when nothing is done to repair them? The team will become much faster if it can improve the quality on its own by removing known defects and making the software better. Then the team will be able to take on more audacious goals instead of being weighed down by quality problems. Moving known defects to the top of the Product Backlog places quality work as a central goal for the team to achieve which directly improves the product, makes customers and users of the software much happier and invigorates the team to continue to become more effective. Placing known defects away from the top of the Product Backlog causes morale challenges, acceptance by the team of poor quality work and creates an atmosphere of apathy. These are likely to cause a failure by the Scrum Team to deliver on its goals.
The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum. The User Story format is an effective way of communicating end user value to the Scrum Team. The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system). A User Story is made up of three “C’s”: Card, Conversation and Confirmation. The Card is the written version of the story (usually a physical card on the wall). It is considered to be an “invitation to a conversation”. The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card. Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story. A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them. Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this. This is just enough information to make sure that an effective conversation occurs.
Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)
Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards
- The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
- The team looks at the item with the highest value.
- Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
- Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
- If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
- The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
- For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
- Once explanations are complete, the team members collect their cards and go back to step three.
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes
The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.
The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.
Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.