Over a million developers have joined DZone.

Rewind Your Mind

DZone's Guide to

Rewind Your Mind

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

“A good engineer thinks in reverse and asks himself about the stylistic consequences of the components and systems he proposes” – Helmut Jan

This advice is not limited to engineers. It also applies to many of us who want to produce software that actually matters to people.

Thinking in reverse, yet leaning forward can yield innovative results. This can be especially helpful when you feel as though you’ve become stagnant in your day to day activities.

Applied to Lean Startup

As the Lean Startup movement continues to gain momentum, one has to be careful not to blindly speed through the Build -> Measure -> Learn loops.

As Eric Ries stated in his Mixergy interview, even though you act in:


You need to first think it through in reverse:

What do I need to learn?
What do I need to measure to learn?
What do I need to build to measure to learn?

It may sound awkward, but the subtle shift in thinking really blew my mind when I first realized how it would affect building out minimum viable products.

Applied to User Stories

Mixing things up can also help you inspire innovation when writing User Stories. I was first introduced to this by Lyssa Adkins a few years ago.

Instead of following the standard User Story format of:

As a user,
I want feature,
so that benefit

You can work in reverse from the end to the beginning:

So that benefit,
I want feature,
as a user

This forces you to think about the benefit first, and then trace it back to what feature would provide that benefit. You can then trace the benefit back to the user.

This subtle shift in the way you approach writing User Stories can profoundly affect how you think about your features. It may help you realize that a benefit or feature you initially thought was useful does not have any user demand.

Applied to Behavior Driven Development

Another method of applying this technique is with regards to Behavior Driven Development.

Instead of following the gherkin approach of:

Given context,
When event,
Then outcome

You can work in reverse from the end to the beginning:

Then outcome,
When event,
Given context

Doing so will help you think about the desired outcome, to the event that triggers the desired outcome, to the context that surrounds the event that triggers the desired outcome.

There are other applications of this reversal of thinking, but you should get the idea in the above examples. Try them out when you feel as though something just isn’t working and you need to shake things up.

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}