I’ve been working with the Agile methodology for many years, and I consider myself to be a seasoned veteran at this point. I would not say that I’m an expert. The truth is that even if you have been doing this for years, you may still not have truly mastered the art of using Agile effectively. There will be many improvements to your overall development process, but there will still be days when you will question its effectiveness.
I had one of those days this week, during Sprint planning. In this article, I’ll talk about a few of the challenges that can arise in Agile during the Sprint Planning process, and also talk about some strategies that can be used to make the process more effective.
Delivering Business Value
Stories are generally written from the perspective of a user, but not all stories fit this mold well. For example, a team may need to refactor a backend API to use micro-services in order to more effectively scale in the future. From a user perspective, there will likely not be any visible changes. You could write it up as “As a user, I would like the application to continue to be responsive as more users are using it so that I can continue to do my work without significant delay” or something of the like.
While the description of the story is accurate, it doesn’t truly capture what needs to be done. In fact, it is too open-ended to be an effective story. There are numerous ways that the application could be modified to maintain the responsiveness of the application, but the intent behind the story is to address a concern that could lead to performance degradation in the future.
The complication is that stories are intended to deliver business value. This means stories should provide real value when the work is released. If a story doesn’t add value to the business, why are we doing it? The problem with this kind of thinking is that sometimes you can’t deliver user business value with just one piece of the puzzle. For example, a story may describe adding a new service API, but it won’t actually be usable until database changes are done (and the required changes are captured in a different story).
In my mind, not all business value has to be about the user. Sometimes you have to do work so that later on developers won’t end up having to do even more work, or even worse, completely start from scratch. There is business value there, but it will be value to the team building the application (which translates into business value for the whole company over time). It can be hard to justify this work to non-technical people, but they will understand if you can provide details on why not doing that work will cause pain down the road.
To address this, I’ve seen teams use a strategy called a Technical Story. This kind of story is still written from a user perspective, but the users are the development team themselves, and technical requirements are allowed to be specified as part of the story. “As a developer, I need to update the version of this library so that we can scale the system effectively in the future”. This lets us still keep to the spirit of Agile stories without trying to justify business value to a customer.
Keeping the Discussion Around Requirements
Another tricky aspect of planning is staying away from implementation. When developers start hearing requirements, they are generally already thinking about implementation details. Developers think about these things because we want to be able to say with confidence that we can actually deliver the requested work on time. Unfortunately, this can often derail the planning discussions and make them take much longer.
The problem is that you start wandering away from what is actually being requested and focusing on things that don’t belong in a planning meeting. It’s as if someone asked you to look up a phone number online, and you start discussing with them which browser and search engine you are going to use. The person asking you doesn’t care how you get the information, as long as you do get the information.
If you don’t know whether you can deliver the functionality at all, what you really need to do is to create a Spike and defer the story until after the spike is done. The spike is essentially a time-boxed research story so that we can answer the question of whether the work can be done. Given that we can do the work, the conversation doesn’t need to go into the details on how.
Another reason to keep the discussion around the requirements is that development teams work better when they have the freedom to choose the best tools they can for the job. I’ve worked on teams where the implementation was dictated by the business, and it generally ends up being a grind as the development team ends up working harder to make a bad solution work. By keeping the boundary where business requirements are on one side and implementation details on the other, both sides will be more satisfied with the process in the end.
Don’t Start Until You Are Ready
One reason companies sometimes don’t like Agile is that there will be push-back from the development teams when stories aren’t quite fully groomed yet. Upstream in the process, expectations have been set on when some functionality can be delivered, and so there can be pressing deadlines that make stories rise in priority even though the details are still being worked out.
A team that is given an ungroomed story can face difficulty in effectively deliver what the customer actually wants. You will hear the term minimum viable product (MVP) used a lot when defining requirements, and for good reason. Establishing the MVP helps the grooming process by narrowing the scope of considerations that need to be made when defining expectations. The MVP doesn’t have to be the end product, but rather a stepping stone along the way to delivering the real solution.
Stories that become too large (generally more than a week or two) have to be broken down, and sometimes that creates more work on the business side. It takes time to write stories because you are not only stating what the user wants, you are also stating the criteria that will be used to judge whether the work will be accepted into a release. Development leads may have to be involved in this process to help the business write the stories, and this can impact the capacity for the Sprint (time spent planning is time not spent developing).
This may sound like Agile complicates the process, but in fact, this process of refinement is a really important one. A lot of the initial drafted requirements tend to end up being less important or dropped altogether. One statistic I’ve heard is that up to 50% of all features in applications are rarely used, which basically means developers are doing a lot of work that won’t actually turn into real business value. By going through this process, we hope to not only capture what the business wants, but also whether it actually does provide business value. Although it may take more time to get a story ready, that effort pays off big dividends in the end.
In this article, I’ve talked about some of the big challenges that teams can face when going through the Agile Sprint planning process. I talked about the importance of delivering business value while still addressing technical issues that can cause pain later on. Keeping the discussion around requirements can help the team stay focused on what they need to deliver instead of straying off into how it will be delivered. Ensuring that stories are really ready can help the team deliver the most business value for the least amount of work. These are just some of the techniques teams can use to be more effective, and I use them every day as part of my work.