New job, new product, new team, let’s make sure we start as we mean to go on and Get This Right! Right?
The product might be new to me, but it’s been around for about a year or so. The result of a project that ran out of budget somewhere during Alpha and was put live anyway, there’s already a long list of things that the users hate and that need to be fixed, but almost none of the entries in that list stand up to any kind of quality review for a Story.
Most of the original team have left and half the new team only were only due to arrive during the second half of what became the Sprint, so with the backlog in such poor shape, we were nowhere near ready for a Sprint to start.
I started a sprint anyway.
With a couple of days to run this sprint, the burn-down looks like this:
That big spike on day 2? We added one Story to the Sprint because it had one Task still open even though the Story itself was closed. It brought loads of work with it (work goes up) which was already done (work goes down again).
That cliff on the right-hand end of the red line? We dropped a Story into Sprint 2.
The long expanses of horizontal lines on both red and green? People weren’t used to updating their tasks, so didn’t.
Two people joined the team on April 12th. One of the existing people went on paternity leave on April 8th. Two people were on holiday until April 11th.
If our goal was a pretty burn-down chart, starting a Sprint was a terrible idea.
My actual goal was to highlight to everyone that would listen that getting Stories into a good state before you start a Sprint is important. Not because it lets Jira draw a pretty graph, but because the ugly graph is a symptom of a team that doesn’t know what it’s supposed to be doing. It’s clear from the interactions I’ve seen between the PO and the developers that priorities have been changed on a day-by-day basis, that nobody really has a handle on enough of the detail of any of the work and that I’m going to be gainfully employed here in this role for several months to come!