How do you really know enough?

Every now and again we discuss failure to reach a  sprint goal – or just how our sizing is going.  Currently a team that I’m working with is tracking whether their sizes  were higher or lower than they expected so that they can gather data to learn more and possibly understand how better to size stories.  When these types of discussions come up,  inevitably the level of detail specified in the story is held up as a problem.  There is too little.  It hasn’t been thought through and specified
enough.  We spend too much time talking  about details that we discover when we’re in the implementation of the story.

Every now and again – less frequently I think – I get the  opposite discussion where developers push back on too much detail as a solution  is being presented instead of a problem to solve and the developers lack sight  of the business intent.

I find this a continuous balancing act.  It is a balance that I haven’t perfected
between my team and my PO yet.

We recently have had the former issue again – “too little  information”.  In previous retrospectives  we’ve started tracking our sizing.  I’ve  also encouraged the teams that if their understanding of an issue changes – we  either need to re-estimate – if it isn’t in the sprint yet – or if the scope has grown in a sprint story, then a new story in the next sprint may be  needed.  This isn’t often taken up though.

In the most recent retrospective we grouped a bunch of  things under the title “understanding”.  The team acknowledged that maybe they weren’t spending enough time in SP1 & 2 in order to fully understand the work as clearly as the work was in theory obvious.  But when digging into the work requirements emerged and understanding grew and subtleties that were there all along were fully realised. This is all too often blamed on the story.  The spec isn’t detailed enough.  The PO didn’t write it down.  I spent too much time in the last sprint
asking questions and discussing things. This in inefficient…

I must be a little fair – our PO is in Europe – so the turnaround time on questions can be longer than a collocated PO.  This is a challenge.  And sometimes he also goes on leave.  But more on that in a later blog post.

This all made me think of when we were in early Scrum adoption.  I sent an article around that talked about story definition.  There was much amusement in the team around the variation of “a story is a placeholder for a future conversation” in the article. And much ridicule that it was just an excuse to write bad stories and not to spec anything.  We’ve come a long way along the Scrum path since then.  But I still get frustrated every now and again when if a perfect spec isn’t supplied and someone needs to try and work it out – either from how it works now – or from discussions with the PO – that this is bad requirement specification and someone should have spent vastly more amounts of time working on this earlier so that a conversation didn’t need to happen now.  Alternatively – someone should have documented how it worked in great detail in previous years (though it’d be out of date by now inevitably…).  Thankfully
this doesn’t happen too often these days.

So what did we do for the most recent situation?  The team acknowledged that we need to actually use SP1 & 2 a bit more effectively.  We’ve started incorporating three questions for each story that we will be more actively asking instead of passively assuming.  These are
1. What is complicated about this story?
2. What are we going to forget about this story?
3. How is this story going to be tested?

Yes, some of these should be asked anyway – but making these more explicit with the team’s acknowledgement of the problem will hopefully make them more likely to happen in more detail.  We’re hoping this will generate additional conversation that will help increase the awareness of what the work is and the subtleties that we aren’t engaging in.  We shall see.

Do others out there also encounter the “this story isn’t defined enough” complaint?  (After it was sized and taken into a sprint.)  What are
you doing to counteract this argument?  Is it all about using SP1 & 2 more effectively?  And what tips and tricks do you use to enable the conversation to be more effective?

Hopefully one day I’ll find out how best to write a story that would make Goldilocks happy – not too much, not too little, but just right.  And hopefully one day I’ll work with developers who won’t think that the story being a placeholder for a conversation is such a farcical idea.  Though I must admit – it probably would be better receive now.