From Story Points to Continuous Learning

Andy McGrath Coaching, News

‘Our 3-point stories are getting carried over because once we started building it, we found out it was much more difficult.  What should we do now?’

We coaches hear this in a lot of different environments, especially with product teams working in legacy code.

Yes, what do they do now?  And what do they want to hear? That depends on their role.  Scrum Masters or Product Managers may want to understand how it affects burnup charts. Testers may want to know if they should file defects. Engineers may just want to get back to work.  And if you’re trying to learn product incrementally, you yearn for smaller stories, and this scenario may come up frequently.

Instead of answering that question from a tracking perspective, I work with teams to try to think about how they might be able to handle these situations instead of answering the almighty question of “what to do now.”  Here is what we do:

  • Move estimates from ‘promise of delivery’ to ‘invest in learning’
  • Invest in intentional planning instead of accidental working
  • Use acceptance criteria to constrain our current understanding 
  • Don’t wait for the demo to get feedback

Shift Estimates From ‘Promise of Delivery’ to ‘Investment to Continue Learning’

This is the big mind shift.  Estimates were never about ‘all of this will be done no matter what, and then some.’  An estimate is just that: a guess, based upon our best current knowledge.  Regardless if you want to estimate or not, the idea behind building products is the same – ‘Based on what we (not I) know, this is roughly how long it might take.  At worst, we should check in after small investments to reflect on what we have learned.’  

Story points don’t make discovery and learning magically go away.  Instead, they’re a nice conversation piece around how much do we want to invest in this.

Invest in Intentional Planning

It is not a big secret that DevJam values product teams working together to understand the problem space – using conversation starters such as collaborative chartering, personas, and story maps.  We do this on purpose – when teams invest in having a better common understanding of their space, less unknowns tend to pop up.  Or when the unknowns occur, the team understands that no one saw it coming and acknowledge the learning aspect.  When teams don’t invest in these directed conversations, teams end up discovering more work along the way and the conversation quickly turns into ‘is this a new story, a defect, more points, etc?’  When really, the problem all along was a lack of intentional planning.

Use Tests and Acceptance Criteria to Explain Current Understanding

Acceptance tests are a really nice way of capturing what we understand about the story.  Acceptance tests were never about the order of the drop downs or about the color of the buttons, or even about clicking on the button – small, common distractions.  Acceptance tests are about a product group coming together and saying ‘this is what it looks like when this step is solved, here are some things that might go wrong and how we want to help our consumers along the way.’  It doesn’t need to be more complicated than that.

I see teams building APIs on legacy code and their tests are ‘all scenarios pass’ – which is roughly 1,000 scenarios.

And you know what happens?  4 of those 1,000 tests fail on real weird edge scenarios, so the story is extended.  But realize that story is extended because the product team didn’t say ‘what do we know about this story and when it would be done?’ That is the root, not the edge tests.  The edge tests are a new team conversation: hey, look what we learned!  What should we do? Do we want to invest more?

Don’t Wait Until Demo for Feedback

We all know that stories can be demo’ed before the end of the sprint, yet rarely do I see teams getting together for a few minutes every day or so and just asking one question: ‘is this still what we all were thinking?’  This simple exercise reduces so much noise as problems are addressed in near real-time, rather than when there is much more time and emotion invested.  Couple this with teams focusing on delivering experiences and iterating through that experience as it is built, and you have a really nice situation.

So the next time you come across those stories that are just spiraling out of control, talk with your team and see what is really happening. Keep it simple. Maybe one of the pointers above can help you?  Let us know what you try.