I always had this strange feeling as a developer. Our Trello board came to life following Kanban principles straight out of our college text books. Tasks entered the process in the To-do column and moved along nicely. You could choose any one of them from To-do List to implement. Of course, my boss always wanted us to take the topmost cards, so prioritization wasn’t an issue we had to worry about. If he wanted to get something done quickly, he just dragged the task to the top and sent out a quick memo so someone could jump on it right away. We thought had the perfect production line running – but did we!?
This is how Kanban board started failing us
As the project grew bigger and bigger more and more tasks started stagnating at the bottom of our backlog. The company hired new employees which meant more resources were at hand which lead to even more tasks piling up in the Trello lists. Once in a while we got together and decided to “fine tune” our processes which introducing new columns to our Trello board.
Why improve something that’s already a masterclass – you might ask?
No, this wasn’t improvement, it was a must, just to make room for the sea of cards. At its peak, we used labels marking releases so we also used our Trello board for roadmap planning. After a while my boss found himself micro-managing the development team and all its tasks. He reorganized the To-do, Next and Upcoming lists several times a week to get tasks delivered more rapidly.
This is how a developer sees agile product management internally
As a developer I found that I had less and less information about what I was working on and what needed to be done. The tasks where completely randomized (some said: prioritized) and found myself asking questions like
- “Does this task contribute anything to the project at all?”
- “Who came up with this task, how will I figure out what to develop?”
- “Will it be OK if I implemented it this particular way?”
I always had to ask someone to guide me to someone who could explain the whole idea and context of a certain task. The lack of context of the tasks was frustrating and made me look like a complete noob asking so many questions just to begin implementation.
Centralised decisions and knowledge hinder shared understanding
I also had the feeling that the know-how we had about a project only existed in the minds of Ashley, Nick and Ryan – the three top brains at our company at the time. All the information was available in this triangle but only existed there and never trickled down to the tasks themselves. We had to realize we need a solution and user story mapping helped us in three key areas:
- it helped to put every task in context
- by giving a big picture and a holistic overview of the project
- which helped develop shared understanding throughout the team and the external stakeholders.
I’ll explain how through some examples.
Putting every task in context with user story mapping
For a kick-off, the user story mapping technique doesn’t talk about tasks but user stories instead. It places the end-user in focus and tries to map out some of his or her goals and the steps along the way towards that goal. This was a big change in our perspective how we approached our projects.
To help us get along we all read Jeff Patton’s User Story Mapping book (O’Reilly, 2014) and started putting sticky notes on our office wall. All the little pieces of paper had only one sentence formulated like so:
If you answer the questions who, what and why and fill in the gaps you get user stories like:
It sounds silly, but believe me – if you can deliver on that, you’ll win. If you can build an online clothing store and focus on the user and his goal that way, you’ll be killing it.
Bridging the unbridgeable gap between the client and the developer
If you’re doing a project for a client of your’s, start showing them stories like this. Since they’re more in the clothing business, they instantly know that this idea to show the latest shirt on the front page will bring them a fortune. They’ll be happy to participate and help you in planning.
Once the plans were ready, we continued to support development with Trello. The implementation team now knew more about the cards than ever before. A slight context gives so much more value to each card and you can focus on delivering stories with the highest value to the end users.
How does user story mapping help developers?
Instead of receiving tasks such as:
- list clothes,
- implement a car,
- implement checkout,
we had more meaningful planning sessions then ever before. After a while we introduced smaller sticky notes representing the statuses for the stories – kudos to the sales guys at 3M who ‘invented’ the eights-sized Post-its for only half the price as their bigger brothers. The smaller cards marked three statuses:
- orange when a story was being implemented,
- green when it was done, and
- red when we had to talk it over again.
This was actually a feedback loop from our developers. When they had some technical feedback on any of the stories, we stuck a red sticker on the card and knew what to ask the client next time around.
Clients also became anxious to come over: their whole project was mapped out on our white walls. They got a grasp on the project instantly and could follow the process of implementation. At that time, his was technically available in Trello, but again in a slightly less convenient way. Trello cards could never fit on one screen and were written for developers, not the clients. As one of our clients mentioned earlier: our Trello cards are written for aliens from Mars – we haven’t had such a remark since introducing story mapping in our workflow.
Shared understanding became a thing
This whole transition had an unexpectedly profound impact on how we thought about development. It was a well desired side-effect but was something that’s hard to force into existence. Just when we weren’t expecting it, it creeped in rather slowly but stuck with us ever since. It was a company-wide shared understanding of projects we were working on. Both between Product Managers and Developers and between the managers and our external clients.
Remember the top three guys at the office I told you at the beginning? And how they were the only true holders of information onour projects? The transition to story mapping quietly reduced the number of sometimes awkward questions by at least a tenth.
Estimation on development made visual
Every story you look at belongs to a user step. What step you might ask? A step towards the end-user’s goal. Is it the first step, it it the last? The map shows it clear as daylight. You can check for other stories over and below yours and see what priority it has. By looking at the surrounding stories you can quickly estimate how the project’s progress is going.
Some other pros for the record
Adopting user story mapping soon brought financial benefits. It was easier to keep projects on track. If the client wanted more stuff added to the project – no problem, we added new Post-its to our wall. It was literally growing in a way you could see – negotiating a bigger budget for the project with the client became less stressful, the reasons were visible.
Not all clients are the same, but we had many who came back to us for their future projects, mainly because of the way we could work together with them. The key takeaway was that available budget for a project can actually increase if you can focus on delivering the more valuable features for the client. They will get more in return of their investment so they’re more likely to spend on your work. Mastering user story mapping can lead to a win-win situation.
Some other cons for the record
Rearrangement of physical user story maps takes too much effort
There were some painful points as well. Whenever clients came over with new ideas, adding new Post-it notes in the middle of the grid on the wall sometimes lead to massive manual rearrangements. Imagine picking up and re-sticking a few dozens of notes only 5 inches to the right. It’s not something I liked or I miss having to do. Digital solutions like StoriesOnBoard can handle these tasks with ease.
Having to create a flat backlog from physical story cards manually
Also, making digital task cards in Trello from stories on paper notes stuck to the wall was a pain in the ass. Typically you assign this task to a newcomer at your company, but believe me, doing so isn’t going to lay the foundations of workplace friendship. There are times when it is you who has to roll up your sleeves and begin copying tens and hundreds of cards to the next tool you’re using. Story mapping apps also come as a rescue and let you with send over already formulated story cards to Trello with a single click of a button. A really nice time saver that helps you finish work earlier that day.
My final thoughts: just give it a go
My final thoughts? I’d definitely recommend you try user story mapping. Offline or online – that depends. If you have the office space and don’t mind sticking notes on the wall during project planning – then that’s the easiest way to get started. If you’re co-located with your team or always wish to have access to the latest map online StoriesOnBoard might be a great choice for you.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?