As we continuously strive to adopt agile practices, one of the biggest obstacles we have had recently is dealing with large items on the backlog. What size of an item is too big? Once we have determined something is too big, how should we break it into smaller pieces?
To a developer, the obvious way to break something into smaller pieces is by the different layers of architecture. First get all the data objects completed, then build the middle layer, and then the UI. So by the time you’re building the UI all the back-end functionality is there. This mentality works great in a waterfall methodology because we have thoroughly gathered requirements and we’re not really expected to have anything to show until the end of the project so it doesn’t really matter how long it takes to get something usable as long as it’s all done by the end. However, if we say building the back-end is going to take a full sprint, it doesn’t really fit with agile as that won’t provide any value to the user in this sprint.
So at this point, we should probably ask the question why bother? Why should we try to break this down to a point that we can provide value to the user in a short sprint? Why not just get the back-end done in the first sprint, then the middle layer, and then the UI? So what if it takes 3 sprints? The more I thought about this problem, the more I realized the problem wasn’t really how do we break down these issues knowing what we know, but more of why have we waited this long to break down this issue? If we know enough about a story of this size already to break it into back-end, middle layer, and UI pieces, we have probably done a lot of up-front design. The big question is, was all the up front work correct? The entire point of agile development and breaking stories down to something that can provide value in short iterations is to get quick feedback from the users or representatives of the users. When was the last time we talked to the users? Were they involved in all the up front design? How much time did we spend on that design? Maybe that upfront work we did was not really validated with the users. Maybe we thought it sounded great, but when we start to use it we will realize it doesn’t quite do what we wanted or doesn’t really solve the problem.
So if you are experiencing the problem described above like we are, it’s very possible you are still doing a bit more up front design than necessary. Breaking down user stories should involve the whole team and is much more a functional scope/requirements focused activity than it is technical design/architecture type activity. We should be working on breaking down stories to a size we think can be completed in a single sprint while we are focused on requirements. We should then tackle that smaller piece of functionality and review it with our users to ensure we are on the right path and solving the correct problems. Will this mean we may have to rewrite some our code fairly soon to account for more complex scenarios than we completed in the initial sprint? Yes, it will, that is if we decide to do that more complex scenario. However, we may have learned more about that more complex scenario than we knew at the beginning now that we have some valuable, working software. Maybe this new knowledge will cause us to take a little bit different approach than we would have had we not gotten some quick feedback. If dealing with this amount of rewrite seems like a large risk, think about what is going to happen in a couple years? What will happen when you do release this new functionality and people start using it and submitting enhancement ideas? They will almost definitely think of use cases and ideas you never considered that can’t be just added in with your current design. If we are that resistant to rewriting code, what are we going to do then?
Now that we have figured out that we’re asking the question too late in the process, maybe the how will become a bit easier. In my research for this problem I have found some decent resources. There is a really good post over on Tyner Blain which talks about focusing on personas and solving all the problem for one persona instead of potentially only solving part of the problem for multiple personas. This post also touches on the development efficiency issues. Another great post is from Richard Lawrence’s blog and gets into much more detail about some patterns to follow when splitting stories. If anyone else has any good resources or tips on how or when to split user stories please share.