Good Solution Design — The importance of well worded Stories and asking Why?

Ivan Houston
Jul 21, 2017 · 3 min read

Many will talk about the processes of Emergent Design over Bring Up Front Design.

Some will emphasise the need to NEVER design anything for a potential future need.

In the real world sometimes the team and Product Owner do have a clear vision of where we need to get to in 12–24 months.

Sometime we have to try to see into the future and build applications best suited to be able to handle it.

Context is key.

If you work in an area of complex business, legal or financial rating or underwriting rules your scope for variation and ability to suggest alternatives will be a lot less than if you are working on a customer facing UI and throwing in new usability features.

As track teams focus on short term story design needs that classic MVP scooter might finally ends up not as a nice shiny car, shown to you by your agile coach or senior manager in early training, but more like an overloaded bus running on the chassis of a scooter — not ideal at all.

I am not as well versed on “trained” or being agile, or doing agile right but I do sadly think about these things a lot and I have seen this happen.

Some people take a long time to realise that they are adding to the rickety bus.

So how come we end up with the rickety bus and what type of things could we do to make it a little more stable?

Personally I believe there is a massive potential pitfall here by using MVP in agile in general if someone is not still thinking big and longer term.

You will often here people talk about the Refactoring cycle after initial delivery. If we are being honest with ourselves how often does that happen? Work will continue to be priorities on the bases of customer/business value and other additional features take priority.

Some application component will be more throwaway than others. Some will be rewritten quickly. Others will live for a much longer time.

I have noticed on our track team that Stories now appear on the backlog that are already defined like solutions. Often people do not even see that they are asking for a solution and not the core need.

When I was first introduced to agile Stories were defined as follows:

“As a customer I would like the ability to ….”

Over time that format was dropped.

Partly due to the simple fact that the tool we were using (RTC) did not nicely present the whole story in stand-up view and it was difficult to differentiate between stories on the board.

Secondly when referring to stories there was no shorthand way and reading them can take a while.

Using that format could still not solve the issue but I believe it would be useful and more likely to produce something closer to the core business problem and help in defining the Acceptance Criteria.

When picking up stories or accepting them into your backlog continue to ask WHY and get to the core business need.

I would be interesting to hear how other find this and how they go about wording stories.

Summary

Write Stories that are not solutions

Get to the core of the need (asking Why?)

Think generically

Zoom out to the wider design regularly

Make sure you build in refactoring sprinting or stories

Try to not end up with a rickety bus

)

Ivan Houston

Written by

Working with People in the World of Software

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade