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.

6 comments on “How do you really know enough?

  1. I think you need to talk about why stories as a reminder to have a conversation is such a farcical idea. I think this is the root of your problem, that and your PO being in another country.

    The problem in my mind is that user stories are a project management technique not a requirements technique. Hoping to write the ‘perfect’ story implies that we think written documentation is the best for of communication. In fact I prefer not to have requirements written down, because as soon as they are written down people think they don’t have to have the conversation.

    Not writing them down is not an excuse for the PO not to be super clear about what they want and why. They just might not have thought through implications before questions get asked.

    One more problem which is common. Do you do backlog grooming? Or do developers see stories for the first time in sprint planning 1? Often Sprint planning problems are actually a lack of backlog grooming problems.

  2. patrickvine says:

    Thanks Karen.

    I think the farcical idea was 2 years ago. They are far more comfortable with them now. But the discussion does come up when stories take significantly longer because they actually needed to the PO. That said – perhaps a starting point is to also sit down and talk about what a story is and the expectations between the team and the PO. That is something that hasn’t been explicitly done ever.

    Yip – remote PO adds that pain.

    The “might not have thought through the implications” is the issue that seems to come up most. I think that is why the conversation is super critical.

    We do backlog grooming. And the sprint planning isn’t the first time the team are seeing the stories. But that doesn’t mean that they have fully engaged their brain with everything before they sit down to coding. Just in time thinking is sometimes very just in time. I suspect that is what I need to focus on more than anything.

    Thanks for the ideas and comments.

  3. If you look at the Scrum canon, you’ll notice that user stories do not form part of core Scrum.

    User Stories was a technique which arose from the XP community which had this rare beast called “the on-site customer”. The assumption was built into this context. Then using a story as a placeholder for a conversation, was when you grabbed the card and needed to be reminded what it was about. You looked across the table and asked the customer, “what was this thing again?”

    My suspicion is that this fine tool is now being used in a very different context (distributed team) so I don’t find it at all surprising that the team finds it a bit weird. All too often, as Karen has alluded to, people try to use User Stories as a requirements tool, and this is why I think the team is asking for details etc.

    You might want to ask the question of the team; what format would they like to use for expressing requirements? Reminding them that it needs to be modular enough to provide some level chunking work into small enough vertical slices that will still enable the production of working software.

    The other element I read into your description is that the team doesn’t seem to think of Sprint Planning as work. Work is the stuff that happens once planning is done. An easy way to test this one; does the team look at the product in SP1 or the code in SP2? If not, you may find that the meetings are not being held with the right aim or audience in mind. Ask the team how they could use SP1 & 2 most effectively.

    Lastly, your comments about Sprint Goal and sizing struck a weird note for me. Do you set sprint goals? If so, what does it matter what the size was? It might be useful to think about what level of fidelity your release plan really needs. You might find that you don’t even need to size at all. It might be sufficient just to count stories?

    All in all, I think the time has come to recognise that User Stories and Story Points are not special magical tools which work everywhere and when they don’t the problem is most likely with the people implementing them. I think one needs to think carefully about the context of the team and its needs before settling on a tool. And the best people to help you figure out what that tool should be, are the ones who going to be using it.

    • patrickvine says:

      Great thoughts. Thanks Carlo.

      “If you look at the Scrum canon, you’ll notice that user stories do not form part of core Scrum.”
      I was aware of that. And I like the comments about stories. I think an active look at what we’re doing and (shock!?!) inspecting and adapting how we’re using stories might be in order. I do however think we’re getting far more value from them than not. We are getting the conversations. We are getting some work in SP1 & SP2. Just sometimes it isn’t as much as is needed. And then the conversation takes longer than would ordinarily have taken. So don’t read all the above as a negative comment on the team – but more me pondering how to make this and even better place to work.

      There are still benefits to how we’re working now – the sizing is fast, the teams are comfortable with it – and it forces conversations and understanding that sometimes might not happen. It is a proxy (like the 3 questions above) to get the team engaged in discussions about the work. As such it is still valuable. But possibly looking at the tool as it is – and what the team might need – might help this.

      “Ask the team how they could use SP1 & 2 most effectively.”
      This we’ve covered a couple of times. SP1 they’re committed to and these questions that we’re adding in were part of the team’s commitment to making that more effective. SP2 isn’t as effective as I’d like. But the system is being looked at where it makes sense and sometimes code is being looked at in SP2 to gain insight. But there are still subtlties like hierarchy and permissions implications or knock on effects to other functionality that are only realised when in the real detail.

      “Do you set sprint goals?”
      Where it makes sense – unless the sprint goal is “Fix a list of random user wishes” – I sort find that less useful. However currently we’re working on a 3-4 sprint chunk of work where the goals for each sprint are well defined. If we were releasing every sprint into production then I think this would get far more focused – but the goals are 3 month (or so) releases so I feel the effect gets diluted in that the real goal is the release goals. So – yes – when the work can be grouped into a meaningful goal and not “do some stuff” which does happen all to often in a 3+ year old project.

      “If so, what does it matter what the size was?”
      We have found sizing very useful and effective in giving us reliable deliveries. Strangely the customer (who pays for us to write code) likes this and doesn’t want to change dates too often. But sizing gives me the opportunity to provide an option tree of possible outcomes to the customer and allow them to choose what they want to do – instead of just fixing the date or scope. They like to hit dates for some reason and early and transparent management of that expectation is key for us keeping them trusting us. If I could get them into a continuous delivery mode then possibly we could move away from that. But still – they often want to know a size of a chunk of work so they can compare ROI vs cost of development to make a call. This is great – but it does require us to understand the sizing. I will have a later blog post around this as I continue to ponder if the way I acheive this is agile or not…

      On the other hand – size also links to commitment. If the size of a story grows it has impact on that commitment – as it might be lost if the story is done but grows beyond recognition of the original story. That also influences focus – now the team are spending time on thrashing out unexpected work. One could argue that the team should do that – possibly in the timeboxed backlog grooming – but equivalently the PO can be doing it, allowing the team to maintain their focus on the work that they do have in the sprint – and just pull ideas from the team in the appropriate timeboxed meetings and 1:1 with individuals raising the issues initially.

      “It might be sufficient just to count stories?”
      Hmmm… I have lots of data right now – so I should see if that gives me a similar answer as velocity.

      This is all really great stuff. I have some thoughts to ponder.


  4. […] How do you really know enough I mentioned that one of my teams was gathering data around sizing.  This came out of […]

  5. […] How do you really know enough I mentioned that one of my teams was gathering data around sizing.  This came out of […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s