Stickingpoints

Before start implementing a user story

What step does scrum recommend at the start of the user story?

Estimate the story (often by trusting our guts, T-shirt sizes, story points), we pick the story, we break down the story in tasks and then jump to our IDE start coding…

That’s it?

Well, I have not found any more guides about that.

But there are still some important things missing:

Make a plan of action! Challenge the plan!

We don’t want waterfall, we want agile!

That depends on how detailed your plan is and what’s its purpose is.

The purpose of our plan is not conforming to the plan later.

Our plan is for learning!

And our plan is even more important when starting with a new epic!

How to create the plan?

We start with a brainstorming of our architecture, usually using visualization techniques on flip charts or white boards.

The most important interior in your office is whiteboard all over every wall!

We discuss many aspects and finally agree to an architecture / software design and a plan on how to acheive that.

Then we challenge the plan!

We do a brainstorming to find the sticking points of the plan:

  • What is exciting?
  • What makes us feel good/uncomfortable?
  • What could go wrong?

Writes down some post-its on his own and then we share every ones opinion. The good and the bad feelings. Usually there will be some objections on the plan and then we should discuss that carefully!

What kind of objections might we find? Some examples:

  1. incomplete requirements
  2. contradicting requirements
  3. requirements that can not/hardly be achieved
  4. risks in the software design
  5. risks in the process
  6. some other things

This is not a complete list.

If you find problems in the requirements then immediately go back to your product owner to discuss them. You might have found something that makes the whole story useless. Don’t start coding anything, it will be just waste!

One example for risks in the process: One day we started a big and complicated epic just before holiday season. The team members changed every week and nobody was there all the time from the beginning until the end. After we completed, the service was a big mess because the hand-over communication failed. We had to start over again.

For finding risks in the software design:

Go through every part of the designed architecture in your mind and ask yourself:

  • What will happen if that part fails?
  • How likely is that scenario?
  • How big will the impact be? Huge problem for the customer or just a small annoyance?
  • Will there be data loss? Will there be data mess?
  • How will we detect it?
  • Can we recover?
  • How can we recover?
  • How fast can we recover?

Focus on service boundaries!

Maybe you find that the expected problems are not that serious and you can take the risk. Maybe you find you can implement some mechanisms to warn you before bad things will happen and then deal with it later. But maybe you will have to rethink your design!

Don’t write sunshine software, that only works on happy days!

Write software that is still stable on the stormy days, when the load is high and the network is unreliable and your most experienced operator is on holiday.

failure mode & effects analysis (FMEA)

Once I told a friend about that. He works in engineering. He said that in engineering this step is called “failure mode and effects analysis”. If you are interested, you can find lots of information on that on the internet, for example at Wikipedia↗.

I do not want to propose such a big process monster.

It’s just one thing: Step back and think before jumping to the code.

The sooner you find a mistake, the easier it is to solve.

Any comments or suggestions? Leave an issue or a pull request!