3945310
| Question | Answer |
| In the first half of sprint planning, the team asks questions of the Product Owner to clarify what is to be built. | FACT The information in the Product Backlog is not detailed enough for the team to run with it.There’s still a lot of detail that must be surfaced. This is done through conversation since Agilists believe conversation is more useful than communicating through specs. |
| While estimating PBI size in Sprint Planning is technically allowed, it’s best to estimate prior to planning. | FACT Most practitioners have found that having a session of “backlog refinement” is helpful. The team should understand the story so they can estimate it. |
| The Product Owner assigns development tasks to the Team. | MYTH The team members are the only ones who decide what work gets done, and by whom. |
| The Product Owner is involved in figuring out how code is written. | MYTH The Product Owner is responsible for describing WHAT is to be built. The team determines HOW the WHAT is built. Only the team has the authority to figure out how to write code. |
| In the second half of Sprint Planning, the Product Owner may be needed to help further clarify questions the team has. | FACT Product backlog items need clarification through conversation. This can happen at any time during a sprint, though most issues are clarified in the first half of Sprint Planning, the team often requests additional clarification when they start digging into the items in the second half of planning. |
| The second half of Sprint Planning is for the team to break product backlog items down into development tasks. | FACT While the team may come up with tasks at any time during the sprint, they should do what they can to flesh out as much of the sprint backlog as possible by creating tasks for the stories to which they committed. |
| Development tasks can be sized in hours | FACT While there’s no requirement in Scrum to do this, most teams find it helpful to size tasks with hours. Hours are not used for auditing or tracking purposes, but rather to help team understand work remaining. |
| A rule of thumb for sizing a task is that it should be between 4-16 hours of work. | FACT Many options exist, teams usually don't size tasks larger than 16 hours as that won’t give them evidence of progress, and that 4 hours is too granular to be useful. Experiment with your team to find the size that works best in your situation. |
| Sprint planning for a 2 week sprint should be time boxed to 4 hours. | FACT For a two week sprint, set aside 4 hours for sprint planning: 2 hours for clarifying stories with your product owner, and 2 hours to break stories into tasks. The output of this meeting should be a forecast from the team to the product owner as to what will be completed in the upcoming sprint. |
| Adding a Backlog Refinement session half way through your sprint can help with making the next Sprint Planning shorter and more effective. | FACT A session of Backlog Refinement (a.k.a. Grooming) is very helpful. During this meeting, the team and product owner get together to clarify and estimate stories. Backlog grooming helps keep Sprint Planning short and more effective since POs have a chance to clarify any new stories with the team prior to Sprint Planning. |
Want to create your own Flashcards for free with GoConqr? Learn more.