For the past 6 and a half years I’ve been leading software development in several teams. Over the years, I have implemented changes to our internal processes which have vastly improved the way we make software. However, organizing these processes was challenging, arguably more so than actually making the software.
In configuring our own workflows and researching the methods employed by others, I came to realize that a large share of the troubles that startups face is due to the way in which they use the Agile framework, and from this identified four main causes. Why four? Well, four is the Japanese number of death and that is what projects face when Agile is done the wrong way.
Before developers write a single line of code for a new product, it is crucial that an actual need is identified. Two important questions should be asked at the very early stages of the product development cycle: first, what are the problems which the potential clients currently have; and second, what are the solutions which could address these problems? It is the Product Owner’s responsibility to get the clients on board in the development process and develop the product’s vision.
The clients don’t only influence the vision at the beginning of the project: at the end of every Sprint, another question should be asked: do the clients like the materialization of the solution? Enabling the client, and not just the Product Owner, to provide feedback in the Sprint review meetings strengthens the relevance and usability of the product.
Beyond the Sprint reviews, clients should be regularly asked what they like and don’t like about the application so as to assess the product holistically. Their input can be procured through customer satisfaction questionnaires or interviews; it doesn’t really matter how it’s done, just as long as it’s done. This input is important for not only ensuring that the product is developed with the clients’ primary needs in mind, but also so that the product adapts to the clients evolving needs.
A common way to keep track of progress towards a product’s vision is the use of a story map, which organizes the product’s vision by describing short narratives through the perspective of a typical user, and the activities they go through to reach certain goals.
Stories are critical because they contribute to the most important part of software development: figuring out what to make. A story map, in which the stories live, simplifies this process by helping plan which features solve which needs. Additionally, it helps prioritize the development of features and, when done right, sets clear goals for the development team.
Story maps are essential to maintaining the focus of the product, especially when the focus changes. Which is kind of the point: adapting to the client’s needs is the essence of working Agile.
Everyone on the team has different priorities. And, when anyone can transform their priorities into backlog items, the backlog tends to swell and the product’s vision is lost. Don’t forget, the priority should be to make the product that the client needs. It is the Product Owner’s responsibility to collaborate with the people who understand our business, our customers and the technology we use to develop a product vision through the use of a story map and the product backlog. So, the first thing to do which reduces the bloating of the backlog is by limiting its content to user stories that are directly related to the application we are trying to build.
Secondly, bugs, though sometimes inevitable, are an indication that a previous feature implementation was not finished according to the “definition of done” (see my previous post). They do not require their own story; time is saved by fixing them as soon as they arise and no one should try to create a narrative around what is essentially a touch-up.
Finally, and most importantly, we should focus on providing minimal viable solutions. In 2015, Black Swan Farming calculated the cost of delay per requirement. They found that the 25% most urgent requirements had a value a thousand times greater than the bottom 25%. In fact, they showed that, for them, the majority of the overall cost of delay resides in the delay of only three features. Trimming the fat from the backlog makes it so that the backlog serves as a detailed blueprint for the developers to build as lean a product as possible, as well as allows the Product Owner to understand what is still necessary to implement.
Story points were conceived as a way to predict when the backlog items would be finished and furthermore when the product could be released, mainly as a way to appease top-level managers and align their budget calendars. These story points estimate how much “effort” it would take to finish a story. The idea is that, when one knows how many story points can be done in a sprint, one can project how many sprints it will take to finish all the stories. The problem is, “effort” is such an ungraspable unit and user stories are so amorphous that the estimation it produces becomes highly inaccurate.
In many Scrum environments, too much time is wasted estimating effort points - it is not uncommon for these estimation meetings to last half a day. And, with the cost of delay in mind, it becomes evident that spending time guesstimating inaccurate deadlines is not a smart use of time.
Simply counting the amount of stories provides a projected date very close to one made with story point estimation. The only difference is, it will take about a minute to count stories, not hours.
18 December 2024
10 June 2024
