Shared Docs

At your desk on a rather boring Wednesday afternoon you receive an email from your boss, asking for a task to be completed for Friday morning. They need an “update” on the progress of the biggest project in the department.

“OK”, you say to yourself, task in hand and blinkered to the fact that the email you just received was about to result in at least a day of wasted effort.

Friday morning arrives and you ask your caffeine deprived boss when they would be free for a catchup to go through your slides. You have spent all night preparing up to date burndown charts, bug ratio per developer stats, completion percentage on epic, overtime hours as well as various other metrics that could associated with any project no matter the methodology.

“Oh, when I said update I just meant are we still on track for April 10th?”

How many times has that happened to you or someone in your business?

The misalignment between the written word via user stories or documented requirements to the end result, in software, is not a new topic. However, I’ve never really understood just how simple a mistake can be caused via the umbrella of shared documents until I started to dig into Jeff Pattons “User Story Mapping”.


Now let me first of all say that this is not the first, nor the last book I have read which has spoken about stories and how they can be such a pain to deal with.

In any system or organisation, it doesn’t matter if it’s software development or not, documents are shared around. These documents can contain reports on meetings, data that has been collated via surveys or indeed they can be requirements for a new product/feature that the business would like.

The idea would be to collate all the business’ desires into the one document, containing everything from the basic premise of the feature, why the company needs it, who will use it, how they will use it, security on that feature and even if you are lucky some test cases.

That 50 page word document is then placed somewhere and the work is done, development have what they need to build me my feature. Now, previously, this document would land onto the lap of one unlucky developer to try and understand the document.

The above isn’t a problem (well it technically is in agile methodologies but creating a backlog from a BRD isn’t impossible, in fact I’ve done it before). The problem lies with what isn’t in the document.


If you take the example above that the feature is a simple click to buy page for someone wanting to easily purchase a company product. The document will describe how the stakeholders and product owner got to their eventual desire, but it won’t include what they don’t want it to do, or things they dismissed during discussions as they didn’t think it was relevant.

Now, because a member of the product team is looking to build what is requested, all they can really use is the descriptions of how the feature works as written on the document.

Think about how this Slack conversation I had the other day would have been different in person;

Product Owner: Is X working from home today? (ABOUT AN HOUR PASSES AS I WAS IN A MEETING) Ben: he is sorry Product Owner: sorry about what? Ben: he is, sorry Product Owner: Ah ok….

Now that’s a relatively low cost conversation, nothing was wasted there other than a Product Owner being confused as to why I was telling them one of my team was sorry. Imagine the cost if this happened four or five times during the development of the click to buy feature.

No matter what side of the organisation you are in, making sure that the document you have produced or are digesting makes sense to both parties is paramount to the success of a project.

It’s that simple.

You can do that through various different methods which I won’t go into detail here but simply running through what you are asking for or being required to do with the other person if a very good place to start. How about reducing your feedback loops so that the work is constantly being validated as it goes through whatever SDLC you have in place.

No matter what you are using to build whatever you are building, make sure everyone is on the same page; it just might be the difference between success and failure.



User Story Mapping

Like this or any other blog post; follow me at @bstewart84 on twitter