Differences

This shows you the differences between two versions of the page.

--- team_has_right_to_reject_stories_for_estimation_that_are_not_ready [2016/06/16 09:02] – hpsamios
+++ team_has_right_to_reject_stories_for_estimation_that_are_not_ready [2020/06/04 11:44] (current) – Removed LINKBACK hans
@@ Line 1: / Line 1: @@
 ====== Team Has Right to Reject Stories for Estimation That are Not READY ======
-If work items are not precisely understood, development effort (and time) tend to balloon, which in turn cause the Sprint to fail. Therefore, define
+If you provide garbage User Stories you can expect garbage estimates not to mention garbage implementation. To improve this you let the Team have the option to reject a User Story during the estimation or planning meeting if they do not understand the requirement or if the requirement is poorly formed.
-criteria which items must meet before they can be put on the Sprint backlog.
-This done criteria is often called "ready" as in "is this story ready for a Sprint".
-This is related to [[establish_a_done_definition_for_a_story_to_be_ready_for_the_team|Establish a "done" definition for a story to be READY for the team]]
+If the Team rejects a User Story they must:
+  * Provide a specific view of what is wrong with the User Story. The right to refuse a User Story should not be a way for the Scrum Team to avoid doing something they do not want to do. We also do not want to start playing the Wrong Rock game - see below.
+  * Work with the Product Owner to improve the User Story
+Apart from the understanding of the requirement stated in the User Story,  Teams should use the INVEST model to help improve the User Story.
-~~LINKBACK~~
+Note that it is pretty drastic when a Scrum Team has to rejects a User Story. The leaders of the Scrum Team need to get ahead of the process to ensure that in general this does not become an issue.
-~~DISCUSSION~~
-{{tag>Team Estimates Forecast Points EstimationPractice Ready Story}}
+Teams that have used this approach have found that there is a cleaner discussion of the requirements and therefore the estimates are cleaner. In addition we have seen take on work that they do not understand simply because it is at the top of the Product Backlog which leads to re-work as the Product Owner realizes that they are not getting what they want.
+I don't understand "Wrong Rock"?
+"Give me a rock". "No that's not what I was expecting - give me another one ..."
+"I am reminded of a story Ken Blanchard told when he described a 'Wrong Rock' manager. We have all known these people.
+They tell you to perform a task - for example, 'I need a rock. Go down to the field behind the parking lot and bring me a rock'. You go to the field, find a nice rock and return, 'That's not what I had in mind.' You ask for clarification and get, 'I'm not exactly sure, but this isn't it. Try again. Maybe a little bigger, maybe smoother. Something less obtrusive, I don't know how to describe it, but I'll know it when I see it.'
+Wrong rock managers fail at the first precondition of expectancy theory because they do not help us to know what success will look like. Therefore we do not know if we will be able to successfully perform the task. No knowing what is required for success means we cannot judge what it takes to succeeds or if we are capable of success. Not knowing if or how we can succeed de-motivates."
+From Motivation and Expectancy Theory - Frank J. Navran
+This is related to [[establish_a_done_definition_for_a_story_to_be_ready_for_the_team|Establish a "done" definition for a story to be READY for the team]]
+{{tag>Team Estimates Forecast Points EstimationPractice Ready Story}}