From MVP to Product: A better story map
Easy Agile User Story Maps Version 4 is here with huge performance improvements and a new look
Recently a customer let us know that loading a particularly large story map was, in a word, slow. So we thought it was about time that we turned our eye to performance. This was roughly fourteen months since we released the first version of Easy Agile User Story Maps.
Wait. So you’re telling me that you don’t care about performance?!
No! We love performance-related work at Easy Agile. That said, we only make it the priority when our customers’ success is at risk.
Too many elements
Like most software which has actually shipped, sold a couple of copies and gone on to see a second version, Easy Agile User Story Maps has been built iteratively. We started with an MVP to prove product-market fit and made sure there were no distractions for hypothetical performance issues. We believe the customer’s feedback is the best way to close in on what problems need solving first.
We optimise holistically for a positive customer experience.
Surprisingly, it’s taken more than a year for the word “performance” to come up in our customer feedback. I put this down the quality of the tools we use (React, redux, redux-sagas).
Even more surprisingly, and maybe as a testament to the quality of our users’ backlogs, it wasn’t that hard to reproduce the issue. With a story map containing around 150 epics and 40 versions, the unoptimised story map would attempt to render 6000 elements.
Less than ideal…
The solution
The slowness was caused by our use of react-dnd (React drag and drop) on some of those 6000 elements. There’s nothing wrong with react-dnd. It does a lot under the covers, but it isn’t designed to be used with so many elements.
Like all good solutions, ours was simple. We implemented react-virtualized to render a subset of the elements that make up the story map.
React Virtualized is a fantastic set of components which helps you create a high performance scrollable list or grid of elements (much like a story map!).
It does this by only rendering the elements which are visible (with a customisable buffer), taking the elements to render from around 6000 to, depending on the size of your screen, approximately 50. (A grid of 6 visible epics multipled by 8 rows).
Please note that the 6000 element count is conservative. The old layout actually had multiple layers of nested elements. The new layout is flatter, lowering the element count even more.
With this information, the optimisation seems fairly obvious. Why not just use it to begin with?
Hindsight is 20/20. However, even if I had the chance to re-write the Story Map from scratch I still wouldn’t optimise performance ahead of proving product/market fit. Early customer feedback for a valuable product is far more important than a fast, useless product. You have to ensure you create the right product. Even if it’s a bit slow…
An eye to the future
Along with great performance, Easy Agile User Story Maps Version 4 comes a new ADG3 look thanks to Atlassian’s new Atlaskit component library. An thanks to your feedback, we’ve also added the Status Category and Assignee to the cards.
We’re hiring
Easy Agile is currently seeking a full time developer to help make amazing products like the user story map. We use the latest and greatest technology and have a passion for automation.
