Our Scrum team has had a bumpy few days, drawing close to the end of a story to find out we need to start over with our implementation.
The details aren’t too important for this post. We accepted a story into the sprint that, even reading it through today, was well written. It has a good definition of the requirement and good acceptance criteria.
It describes a user persona and business value.
We decided on an implementation in sprint planning that the team agreed upon and we started to build it out over a couple of days.
As soon as the Product Owner saw the feature in our development environment we had feedback that the approach was wrong and we needed to change direction.
It is quite interesting to think about how we could have prevented the (wasted) effort that we put into the feature before starting over and how the team reacted to it.
Our implementation would have been easy to describe to the PO before we built it out (actually we are reusing an existing UI convention elsewhere in the product) and we would have known immediately that we were off course.
Unfortunately we didn’t describe in enough detail what were planning to build… but should we have? If the story acceptance criteria was met isn’t it down to the team to decide on implementation?
Ultimately that way of thinking isn’t productive. If we build the feature and the Product Owner isn’t happy with it - it will have to be reworked at some point in the future anyway. One positive point is that we sought feedback during the sprint and we didn’t surprise the PO in the demo at the end of the iteration.
So - how can we prevent this happening next time?
If we’d had graphically laid out our implementation to the Product Owner before the sprint we would have had instant feedback that the approach was wrong. A pencil and paper effort that took 5 minutes to sketch would have saved us a couple of days of wasted work.
Now that we’ve discovered Balsamiq - a great wireframing tool - I think we’ll spend more time visualising our approach for the Product Owner in future. We’ll do this during Sprint Grooming when we prepare and size stories.
And - how did the team react?
Well, pretty much as expected with some level of frustration. One really negative aspect is that as well as the work we have to abandon we have to do more work to rollback to our previous state (Come back Git, all is forgiven)
This was a good opportunity to emphasis some Agile principles though. It is frustrating to have to change course during a sprint. A natural reaction from the team might be to say “Next time we have to tie them down to more rigid acceptance criteria then!” or to para-phrase “Next time lets make the Product Owner work harder to avoid this issue occurring again”.
That’s definitely not the answer. As we know BRUF (Big Requirements Up Front) DOES NOT WORK! If we react to this unfortunate situation by forcing the Product Owner into more descriptive acceptance criteria, or into a more “legally binding” contract our next story will take a lot longer to come to us for implementation.
Not only that - it still won’t be descriptive enough to avoid a similar situation because BRUF are never comprehensive enough, they just take a long time to write. And the next time we have to change approach because of poorly defined requirements our only option is to force yet more process on the PO.
Reacting by forcing more process onto the Product Owner is a certain way to make us less Agile. A certain way to slow down requirements coming to the team and a certain way to slow down the delivery of value to the end users of our system.
The correct way to handle the issue is to ask “How can the team describe the implementation better to the PO before we start work?”. Not to say that we should allow the PO to completely guide the implementation but we should be able to articulate our approach before laying down code so that we can catch potential issues much earlier.
Gotta go - we have a feature to rewrite!
