Can you take a smaller bite?

Following on from a previous post - Small stories are cleaner, easier to complete, faster to demo and quicker to accept.

But what do you do when you can't split a large user story into a small enough chunk that still delivers value? 

This XP article is useful - but one of the most useful tools that sometimes gets forgotten is to remember the law of diminishing returns. Sometimes wrapped up in the guise of a single requirement, are multiple smaller/ less valuable features. Look for the portion that's going to give you the most bang for your buck. 

Break everything else out into other stories. 

It's like giving your Product Owner an itemized quote rather than a all-inclusive one, and all of a sudden they have the ability to prioritize better.

You'll be surprised as to what they'll "live with" when they can see how much it costs.

Believe it when you see it

The value of iterative delivery is that it allows you to inspect often.

I'm sure you're all experienced the problem when someone tells you they're done and then you find out later that they were "mostly done - like 80%". 

We all know how long that last 20% takes.

So this introduces two important concepts: The definition of done, and not believing it until you see it.

When someone tells you the requirements are "Ready" you'll want to review that before throwing it into the backlog and bogging down a team.

Similarly, If demonstrating everything at the end of a iteration is too onerous - then demo as you go. 

Whatever you do - make sure the project sponsors and stakeholders see it occasionally as well. This transparency helps avoid other issues.

Analysis Paralysis - The "What If?" problem

You're in meeting trying to understand or solve some business problem - when someone throws out the dreaded "What if" or "How do we handle?" question. Sometimes it's a valid scenario. Sometimes it's an edge case, sometimes you suspect the person has been tripping and has taken it down some weird unrelated tangent.

It becomes a much larger problem when it drags the discussion into an infinite loop; When a decision can't be made because you're trying to handle so many different scenarios it's become a muddled mess. 

At this stage - Park it. 

Acknowledge the scenario, write it up on the whiteboard and agree to discuss at a later time. Most of the time it should end up being it's own scenario covered seperately..

I had a CTO once who was outstanding at this. He'd acknowledge what you brought up, write it up on the whiteboard and say "That's a great thought - Let's put that on the board, finish this off come back to that"

It took me several months to realize he never came back to any of it; Or had any intention to. 

I guess that's less of a parking lot - More quicksand. He's probably a bad example.

...But what if he had come back to it…?

Unless you see a hairball, keep grooming

We've discussed the value of keeping momentum going in a previous post.

One of the things you never want to see is a team stopping because there aren't enough requirements ready or they're not prioritized. I call it the Prairie dog - You should never see the team pop their heads up and ask - what do we do next? You want them focused on getting things done.

I've worked on large programs where this was a serial process and a real waste of productivity. Don't wait until you finish one release before you start gathering requirements for the next.

This is what you don't want to see:

You don't want idle time between iterations and releases. 

What I prefer to see:

You can take this too far though. 

The product backlog is meant to be "purposefully vague" as it gets further down the list. There's no point spending lots of time getting a User Story clean that may be months or years down the pipeline.

So focus on the high priority items at the top of the list - fill out the rest of the wish list later.