Re: Big Stories

Hi, Michael.


It is risk.


Risk of not finishing the huge story.
Risk of the team feeling a failure not finishing.
Risk of not making the whole thing right.
Risk of appearing to have it finished it, but stakeholders or the PO not
considering a single Acceptance Criteria is met - hence nothing is done.


Take the huge story and make a special effort to slice it. You might check:
http://www.agileforall.com/splitting-user-stories/


Benefits once splitted:


Some of the parts might be not so high priority after all, so they might go
to another Sprint.
The team has higher possibilities to finish several parts than the whole
thing.
Acceptance Criteria are a LOT less trickier and easy to check in smaller
stories.
Each smaller part is a victory you can celebrate and encourage the team to
go for the next one.
Simple is always better... :)


One last humble advice: forget slides. Do a small exercise with people
trying to understand something bigger or chopping it into parts. Try a
Story Map of the huge thing and let people involved to find the splitting
points.


Best regards,


---
Martín Salías
<http://CodeAndBeyond.org>
<http://CodeAndBeyond.org>


On Tue, Nov 24, 2015 at 7:53 PM, Michael Wollin [email protected]
[SCRUMDEVELOPMENT] <[email protected]> wrote:


>
>
> Need the bullet points on why not to plan a big story that is the core
> priority but is too big for a single sprint and not easily split. That is,
> trading the V in inverts for the S. :) It's a "holidays" issue.
>
> I'm doing a training slide. Other than cadence and the ability to pick a
> different higher priority story on the next sprint because circumstances
> may have changed, what were the other reasons?
> 
>