Using Scrum to build the right web app for a client–a retrospective
We were recently tasked with modernizing an existing sales and marketing platform for a client. They had rolled up their sleeves and created a version of this platform a few years prior, but now they wanted to modernize the platform for the present and app-y world in which we live.
While the end product was delivered well, what was most rewarding about this project for me was the true collaboration and iteration of the product throughout the process. Here are the things that went right to make this project a success for all involved.
Delivering a true MVP
Early in the project, we determined a deadline for a sales conference and also used that milestone as a true north for the Minimum Viable Product (MVP). This deadline enabled us to prioritize the features–the user stories–that were most important for this launch window. Anything else we didn’t deliver would be delivered sprint by sprint, marching towards a second sales conference.
In this way, we were treating the project plan like a two line Gantt chart:
Deadline 1 - MVP (with priority features)
Deadline 2 - Additionally requested items
Iterating the product biweekly through Sprint Reviews
Instead of settling with a “best guess” group of requirements from the beginning of the project, we showed the client work as it was built and the client used it, told us what worked, what did not work as they thought it should, and what features might improve the experience.
We nailed a few of the core stories and then riffed with the client as made sense. Features were removed from the backlog when they didn’t make sense. New features that enhanced functionality replaced them. The product we delivered adhered to the overarching goals established early, but it looked nothing like it would have, had we taken a more waterfall approach to design and development… in a good way!
Setting the scope reasonably, not restrictively
Because the client wanted us to modernize the existing platform, we used this as a way to arrive at a Definition of Done for the project and underlying user stories. Did this feature exist on the prior website? Was this feature a natural, modern extension of the prior website or something totally different?
We did not undertake new feature requests, except where they made sense as evolutionary jumps for the existing product. For example, adding features to modernize existing functions of the prior website were considered and often implemented. Features which added brand new verticals to the application were not or could be scoped separately.
Using a great, existing base
Rather than try to build something from scratch, our development team recommended and used an established base product and built upon that. In this way, a lot of quality of life elements were already included and we only needed to customize them in smart ways.
The collaborative spirit of the client
What was the biggest component of this process? A client that was able to iterate with us and join us on the journey. Oftentimes, the big hangup to iteration is a reaction to an unfinished website or an unfinished design as not good. We totally understand the reservation, but, in this case, our client could see through the gaps in features early on and work with us to make the product what they wanted. We were able to build component parts of the web app and then tweak it to suit their needs as we went. “I wish it could do this or that,” conversations are better when both client and developer are working together in tandem. As they held meetings internally, we were able to quickly pivot and replace old features with new, more relevant features.
We were on the journey together, getting excited and inspired about ways to delight the end user. The journey was not a straight line, but the destination was everything we didn’t know we wanted or needed!