Splitting things is considered important in Agile planning. It is even more so in BPUF planning where everything is meticulously documented before starting the actual work. The motivation is in the same ballpark as well. The granularity is the main difference. Planning is guesswork in the first place, so why should we do it in the first place? Understanding is the key.
Software is usually a solution to a problem and from time to time a problem of its own. In reality it is more often than not a system of problems. The key reasons we use an empirical process to tackle software projects are all the problems hidden in each and every project.
So let’s assume we want to understand the problem before going on and implementing it. How much do we need to know? Extreme programming introduces prototyping. First you create an executable solution to a minuscule part of the system of all the problems of different shapes and sizes. Then you show it to the end-user to see whether you are doing the right thing or not. That small thing is a user story.
Looking from the perspective of an end-user there is value in seeing functionality that works. To make that visible, some people recommend the user voice format in user stories. That simply means that a story should sound like this: “As a corporate drone I do not want to spend all my time filling in travel claims, because my boss wants some results.” When looking at the story closer, we can stop and stare at every word. What is a corporate drone? What would be the motivation of this end-user? Oh, he is being forced. So there is time involved. Is that performance, usability or both? So what does a travel claim mean?
Soon we notice that we are looking at an epic of stories. It consists of things like “Document a travel claim”, “Implement access control” and “Do performance testing”. Those do not have the user voice. They also sound vague and big. What is the value of any of those items to the end-user? How long is it going to take? The size of the stories has gone down with the split and the level of technical detail has gone up. Most of that will not be done in a month. So what is more valuable? “As a corporate drone I want to be able to list travel claims issued by myself.” I leave the motivation as an exercise this time. That does sound valuable and smaller than the original.
The user story may sound simple in terms of functionality, but we should consider other things that will be required to finish the job which as such have no value to the customer. That includes the performance tests, grasping the idea of travel claims, the chairs in the office, holidays and coffee. When looking at the original story more closely, this end-user does not really want any visible access control. Splitting stories into value-adding bits is called the walking skeleton. The guy may look skinny and ugly, but there is something concrete, not just an architectural detail. In my eyes the perfect story adds value to the customer and fits into one iteration.
My utopia does not end here. The way technical people split their stories into tasks is usually following the general idea of the technical implementation of the story. It does make sense to me too. However the way I see it, even the sprint planning should somewhat follow the walking skeleton model. Even within the sprint there is benefit of having something that can be poked around, shown to other members of the team and discussed. Even if the team does not finish a story during a sprint, an end to end demo helps the product owner to see whether the intent was correct. The most important reason is that the tasks will be split in a way that is understandable to all team members. I hope I do not have to see many “implement”, “test” and “do it” tasks in my new team. They tend to convey the design to one developer only.
What we tried in our first sprint was for everyone to write down their own tasks for each story and after a short while, combine the thoughts. Are there any other good exercises?