Shared understanding with developers

As a Product Owner or Business Analyst, you want to make sure that your customers’ needs are carried through to your developers as accurately as possible. I hope, I’m just wasting time explaining why this is critically important.

Remember the gossiping game you played in school with your friends? Remember how everyone laughed when a long and complicated sentence transformed into something totally weird just by whispering it around a few ears? Now that was funny back then but can really hurt your business when it happens when your client’s needs and requirements get transformed through the long chain of stakeholders’ ears.

Back in the old days

Not much more than a decade ago, the software development process was based on the traditional waterfall methodology. You had a problem, you hired a software development firm. You told them your story which they turned into tens and thousands of pages of long specifications and blueprints.

When everything was well cemented together with a huge contract, the development team could be fired up to deliver the software you dreamed of. You only hoped that it would still be a viable product for the market when a few months or even years had flown by and the software was considered ready and was shipped. However, it’s important to point out that you don’t have to worry so much about shared understanding within the development team because everything was specified in detail, and heavy contracts made sure nothing changed during the implementation period.

You could verify the end result against the requirements and call it a day. However, the product you made might not be the one the client really wanted. At StoriesOnBoard we believe that more value could have been delivered in these products leveraging story mapping.

Rise of the Agile

Things sped up. Creating software products in months or years is not competitive anymore. A complete industry can turn on its head in that time. Your clients demand fast delivery; quick, smaller improvements rather than huge releases. They might even pivot to new ideas during the project. You need to adapt to this, and the agile software development method can meet your client’s needs.

It’s easy to see that fast context switching and keeping up with frequent changes puts a high demand on your developers. User story mapping is a popular, agile way of keeping your development team on the same page with the project’s current status. It has solutions to help your team see the big picture while focusing on delivering the most important and valuable steps for the customer.

The power of user story mapping

The user story mapping technique not only helps you gather and organize your client’s requirements, but the way the map is built up also establishes a backbone for the project. The end-users’ goals and the steps are always visible, they’re always at hand. When the time comes to introduce the project to developers, the power of this visualization kicks in. By presenting the requirements through user stories instead of flat lists of requirements combined with the power of the concept that you always show how a story fits into the big picture lets you transfer information on a whole new level. There won’t be a story you’re talking about that can’t be put in context by any participant.

By going through the backbone first and explaining the big picture, story cards will be much easier to categorize by the developers. Oh, by the way, this works for remote team members as well, who join the story map at a later time. Putting every story in context helps them catch up much more easily.

What’s more, even the client can be involved in deepening the understanding taking some stress off your back. By slicing up and delivering the project in frequent iterations rather than one monstrous delivery the client has a well-defined point where they can give feedback on how they feel about the outcome. They can go into details if needed to further clarify user goals of stories, not much will go astray if this feedback loop is established and operational. The story map lets you add certain changes to the upcoming iterations and quickly put the project back on track. Developers can focus on delivering value at every stage and get constant feedback on their current work.

How do you know if StoriesOnBoard helped or not?

Of course, knowing that shared understanding truly happened can only be observed afterwards. The final judgement comes on the day you ship your product or hand over the project to your client. Just look at the visual feedback written on his face. Is he smiling? If so, you know that the team was able to deliver the right things.

Clues along the way

However, there are little hints coming from the developers that are worth pointing out. While presenting the project to your team, pay attention to the questions they raise. They will see the project from an engineering perspective and probably ask some things you need to ask from your client. The best is to write down these questions as comments on each story card and go over them with the client.

If you hear remarks like “Ah, haven’t thought of that….” or “Good question, need to work on that…” from your client you can be sure that the story went through to your developers, who could ask relevant questions.

The other way story mapping can help is it will point out stories that are just too big to understand. They must be split into smaller portions. Splitting stories will help your developers give better estimations on each story making it easier to meet deadlines and you can ask your client to help prioritize which stories are more important over others.

Believe us, we’ve all been there. Working with a client this way will build a far better foundation for development than the endless lists of specifications and requirements.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 7

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?