Decisions

Recently I tweeted about my team.

 

DecisionsTweet

 

One of the common problems I see when writing user stories is the lack of definition. This definition needs to be at the right time, and there’s no hard and fast rule, and in the scenario below, this was at the story kick off, the last group chat before the coding starts on the story.

Previously the team when discussing our stories often felt that they got bogged down in the details. This is natural as the pressure to get stuff done and our sense of productivity means that we want to just get on with the task in hand. “If I’m not writing code, then I’m not being productive”.

After asking the team to try and be more thorough with the user stories as an experiment and reviewing the results in our retrospectives we realized the benefits that it had on the ability to deliver the feature quickly. With the first challenge completed we then faced out next challenge.

 

“I’m happy to write down in our acceptance criteria exactly what should happen when the user presses button X, but there are several options, which one is right?”

 

There are times when you might find your teams discussing at length which is the correct behavior. If this discussion starts to dominate a story planning or kick off meeting then its time to stop.

 

You Must Decide?

There’s no phone a friend on this one. The closet you may have is to ask the Product Owner, and that might be possible if they are in the planning with you, but does the Product Owner really know exactly what the customer wants from such a specific behavior? With any luck, they will be there to just make a decision, an often based on flipping a coin.

 

“Deferring a decision is deciding its not important.”

 

If your team relents on making these detailed decisions then gaps may appear in your product. If you don’t decide on the behavior of a feature, how do you know which is correct and which is not. This will ultimately result in a misunderstanding further down the line and cause re-work. If your lucky, this lack of definition will be caught by the testers in your team as they believed the feature should behave in a slightly different way, but still, this will be wasted time either discussing it after its been coded or re-work if you change your decision.

 

But What To Decide?

The stark reality is that you do not know what the right decision for this behavior is. The Product Owner does not know what the right decision for this behavior is. Some might even argue the customer does not know what the right decision for this behavior is (if asked).

The good news is, is that it doesn’t matter.

The paralysis and time spent discussing what is or what is not the right behavior and whether either decision has value to the customer is just waste. The best thing you can do is make a decision regardless of what that decision is. As long as everyone is agreed that a decision has been made. The time spent deciding on the decision is value wasted while your feature is not in production. The quickest way to validate whether the decision was right or wrong is by putting the behavior in a production or a per-production environment where real users can use it under real conditions.

The ability to do this quickly and shorten the feedback loop or PDCA cycle comes with techniques such as Continuous Delivery. The journey to Continually Delivering can be a long one with many challenges of its own, but even if your are only halfway there eliminating the waste of deliberating over small behaviors will be beneficial to both you and your users.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>