[SCRUMDEVELOPMENT] Big Stories

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

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?

[Wouter Lagerweij [e-mail] [SCRUMDEVELOPMENT]]

Hi Michael,

A little sleep addled, but I think depending on who you're talking to and
the situation, reasons could be:

- risk: smaller chunks are easier to estimate, so there's less risk of
surprises. Bigger stories hide complexity, larger variation, yada yada (E
and S)
- risk: no matter how much we say 'we need it all' (cop out!), there are
always priorities within a large story. Not splitting means not thinking
about those and running the risk the less important thing is worked on
first. (V, N, S)
- risk: a large story will be less detailed, and a bigger chance of being
misunderstood. and since you'll find out late about that (because it's
large), you might find out *too* late (S and V)
- 'not easily split' is a cover for not wanting to deal with the
'negotiate' part of INVEST. Lazy. Also doesn't leave room for managing on
scope (where's the value), sprint goals, etc. so, you know, risk. (N, V)

Wouter

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
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?

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Whenever a developer says that a story can't be split that means they
either don't know how to or don't want to. If they respect you enough to
tell you which it is then it is possible to solve the problem and split it
with the right help.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
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?

['Voris, John' [e-mail] [SCRUMDEVELOPMENT]]

And I guess I would start the conversation with . . . Mr. Developer, you
are not going to build a single test for the whole story. What areas would you see
yourself breaking the story as your create various tests?

Would that be a logical view to encourage him to split the big story ?

- John Voris

Re: Big Stories
Tue Nov 24, 2015 3:24 pm (PST) . Posted by: "Adam Sroka" adamjaph
Whenever a developer says that a story can't be split that means they
either don't know how to or don't want to. If they respect you enough to
tell you which it is, then it is possible to solve the problem and split it
with the right help.

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

One of the underlying problems in my view is that the team is small and underpowered. So a story like compare two information sources (10 fields) and display/highlight any differences is too big. So get and display the 10 fields from A is one story, get and display the 10 fields from B is another story, and compare and display the discrepancies is the third story.

Most teams I know could do the whole thing in a day or two. This one will take two weeks each. I want them to discover for themselves the issue. (It was exacerbated by the holiday.)

They are new and just forming as well. Being a cross functional team is novel to this department. Being empowered to ask for what they need may also be new.

[Martín Salías [e-mail] [SCRUMDEVELOPMENT]]

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>

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
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?