Retrospective on overrunning story

It can happen to any team – a user story that was originally estimated for 1 sprint, becomes a never-ending stream of unexpected issues. In our case – we spent 4 months(!) working on a story like that. Soon after, we dedicated one of our retrospectives for a discussion about what happened.

Story timeline

We invited everyone who wrote any code for the story and its stakeholders. Wanting to focus on the biggest issues, we time-boxed the session to 1h and worked with the diagram shown below – a sneaky timeline with 10 placeholders for biggest blockers. Initially the team felt like we didn’t have enough placeholders (bad memories!), but we discovered that it was just enough ).

IMG_1557
Story timeline

Having top 10 blockers listed on the timeline, we ‘dragon-voted’ (see the little dragon stickers on the wall?) for the most painful blockers. The ‘winners’ were then discussed in details. We debated whether the problem was related to:

  • people
  • process
  • tools
  • anything else
IMG_1566
‘Dragon voting’

Back in time

The next task was to… come back in time. The actual question was: “If you knew all what you know today – what would you do differently starting the story again?”. Or in other words: “Come back to the time when the story begun and start over. What do you do?”. That was a very good debate.

Upgrade or not upgrade – that is the question!

One of our big issues was upgrading legacy code to newer version of Java. That caused countless numbers of issues that we didn’t expect. Someone said – ‘We shouldn’t have upgraded to Java 8’. But – is this really the best solution? The legacy code would remain legacy and technical debt would keep growing. The problems we experienced would be delayed in time, but they would still happen at some point.

Could we have avoided any of this?

Surprisingly, we could not have. We could have made it less painful though. Our conclusions were as follows:

  • Talk to people outside the team.
  • Make sure that pre-prod environment is identical with prod.
  • Contact teams we depend on sooner rather than later.
  • Share the knowledge, i.e. as a ‘quick guide’.
  • Research more up front if risky decisions need to be made.
  • Always try improving the current process.

Celebration

Each story that unexpectedly becomes a project should be celebrated when done. We reserved the last few minutes of this retro for a glass of Prosecco and a slice of cake. We deserved that! Also, it helped us to ‘upgrade’ our relationship with the stakeholders and make it feel less stressful.

 

 

 

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s