57725Re: [SCRUMDEVELOPMENT] Handling small change requests
- Feb 12, 2014
Thank you very much for giving better clarity on this point.
-VikramOn 12 Feb 2014 21:42, "Steve Crago" <cragos@...> wrote:Matt:As you probably know, small tweaks can often lead to big problems if they haven’t been properly discussed and integrated into the process.Is the UAT phase part of the Sprint for the features that are being tested?You mention that these requests often come during the UAT phase. Are the requests based on observation of what’s being seen during the UAT?, in which case is it either a missed feature or a defect?Regardless, you do not want to do a 1 day sprint just for this “tweak”. If you start doing this type of short sprint, then you will train your client that this is acceptable and they will begin to expect it every time.Another thing to consider is whether this is a change versus a clarification. The Sprint Goal should not be changed, however, it is tolerable to allow a clarification. Ken Rubin, in his book “Essential Scrum: A Practical Guide To The Most Popular Agile Process”, does a good job of differentiating between the two:“A change is any alteration in work or resources that has the potential to generate economically meaningful waste, harmfully disrupt the flow or work, or substantially increase the scope of work within a sprint…..Clarifications are additional details provided during the sprint that assist the team in achieving the sprint goal…”When a request like this occurs, we meet with the team and we look at the business/customer value of this change before making a decision about agreeing to adding a “small tweak”. If the business/customer value is not significant, then it can be added to the Product Backlog and prioritized appropriately.Keep it in perspective, IMO if it’s not extremely important to the business/customer value then it can wait for the next sprint.Steve CragoOn Feb 10, 2014, at 9:23 PM, mattellenburg@... wrote:
- << Previous post in topic Next post in topic >>