Do you work in tech and have to deal with pesky business analysts or project managers? Are you a project manager and have to deal with flakey development and testing estimates? Have you spent months working on a specification document only to spend more time arguing with everyone else? Worry not, there is an answer.



I suggest trying an impact map.

OK you may say, but I have already written a spec doc, is this not a waste of time? Well let me ask, who you are sending this spec doc to? Is it hitting the head of dev and possibly the head of test? Whats the usual plan after that? The head of dev allocates it to a dev team and they start writing code. At the same time the head of test allocates it to a test team and they start writing tests? This is the usual working way. But the main problem I have with all this, isnt really the handovers, or the time delay, or the confusion in requirements, it is, where is the customers needs in all this?

OK the argument could be that the needs are outlined in the spec doc, possibly in the inital page. But the more hands the doc goes through the more complexity gets added and the further away we are from getting the customer their needs.



So how can an impact map help?

Well the start of the impact map is the goal. The goal is a small simple outline of what the customer needs. Non techincal just a simple problem. It easily answers the question, why are we doing this? If any of the impacts or deliverables dont feed back to that goal, then are they really needed? Probably not, so why waste time developing, testing and building them?

Next we outline who the customer actually is, the user of our system. Here we may actually find out we have multiple users. That’s ok, once they all link back to our goal. Maybe the software we are building will have both internal and external uses, so we may have different requirements for each user.

This leads us nicely into part three of the impact map. The actual impacts. So what change can we make that will help our user achieve their goal? Don’t think technically here. Instead of saying “add a button to a screen that allows the user to access the next page of the app”, say “allow user to navigate the app”. This means that instead of getting bogged down in technical details, we are just outlining the problem that needs to be solved. The details can come later. If there is still a spec doc somewhere, now you can get impacts from it. You may actually realise that some of the things that where in the doc don’t tie back to the goal. Awesome, you have just removed waste.

Ok now you should have something that has a goal, a few actors and some impacts. Whats next? Well now we come up with deliverables.

This is where we can break down the impacts into smaller features or goals with customer value. The output of this could be epic stories. These can then be broken down into smaller stories. I suggest using specification by example to help break down these larger stories. Once you have smaller stories, you now have a backlog that your team can start working on.

Not only will this make sure every story you work on is adding value to your customer, it will also remove some other pesky problems with spec docs. There will be less misunderstanding over requirments, as everyone was in the impact mapping sessions and it’s visable to all. Also instead of having to deliver everything at once, you can now just focus on areas which will add the most value to customers first, then add the rest later.

So hopefully next time you either get a giant spec doc, or have to write one, you could try using an impact map instead. I have used them to great value, and hope you will as well.

Further reading on impact mapping can be found here: https://www.impactmapping.org/.