Team Has Right to Reject Stories for Estimation That are Not READY

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.

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.

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.

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

Use the following URL for manually sending trackbacks: http://www.hanssamios.com/dokuwiki/lib/plugins/linkback/exe/trackback.php/team_has_right_to_reject_stories_for_estimation_that_are_not_ready
What Can We Do To Improve Our Point Based Estimates? Or “How do we improve our point based estimates and resultant velocity?” Backgound We focus on making story points a true measure of the relative size of the work, and velocity as the true capacity of the team to complete requirements to done.
 
You could leave a comment if you were logged in.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/team_has_right_to_reject_stories_for_estimation_that_are_not_ready.txt
  • Last modified: 2016/07/03 13:38
  • (external edit)