Breaking a project's first User Story in to tasks [closed]

Question

I'm starting a new project from scratch and have written User Stores to describe how a given user will interact with the system. But, I'm having trouble understanding how to break the first user story in to tasks without the first one becoming an epic.

For example, if I were building a car and the first user story said something like "As a driver, I would like to be able to change the direction of motion so that I don't hit things.", that would imply a user interface (steering wheel), but also motion (wheels) and everything necessary to link those together (axle, frame, linkage, etc...). In the end, that first user story always seems to represent about 40% of the project because it implies so much about the underlying architecture.

How do you break user stories down for a new project such that the first one doesn't become an epic representing your entire underlying architecture?

Liberticide

I'm voting to close this question as off-topic because it concerns organizational practice, not programming. – Weiland

I'm voting to close this question as off-topic because it is not about programming. – Alenealenson

I'm voting to close this question as off-topic because it belongs on pm.stackexchange.com – Lustrum

Answer 1

You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.

For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.

In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.

Your tasks might be:

• Add an option to the menu
• Add a new gmail authentication screen
• Add a twitter authentication screen
• Add a contact selection screen
• Add a controller that calls into your service layer
• Write a new service that does the work
• Save contacts to the database
• Modify your existing gmail API calling service to get contacts
• Add a twitter API calling service to follow selected contacts

There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).

At any rate, this is a raw sketch of how to break the stories down.

EDIT:

In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.

Iatrics

This demonstrates my problem. Your fist story (being a vertical slice of the system) requires you to implement a lot of your system. This makes it really large (epic) story. Maybe that's just the way it is as @Aaron suggested. – Liberticide

I don't think that this forces you to implement a large part of the system. It [usually] requires you to touch (i.e. modify, extend or add) every layer of your system, but whether this is or isn't a large part of your system depends on the system. In my system an auto-follow feature could be a very small part of a social-aggregator app. It could be deemed maybe 5 story points out of a 200 point system (or if you prefer thinking in ideal days, it could perhaps take the team 3 days to implement out of 3 month release). – Iatrics

This is precisely the issue I'm facing right now. How does one go from ZERO code to something useful. IMO, the first few sprints must define your infrastructure and architecture. Maybe not fully, but there has to be something there. How can I tell how a component is affected by a user story if those components don't exist? To me, that's impossible. What we've done in the past is create some system stories. That define that kind of stuff. That way there is a clear distinction of where the work lies. – Mouser

When using system stories I've always been told "well you're not doing Agile", to which I response..."meh". It's about whatever gets the job done. – Mouser

The thing about agile architecture is that it is always evolving, not planned up-front or completed in the first few sprints. In the case of going from zero to value, I'd suggest that you look at the user story, the acceptance criteria (constraints, UATs, etc.) and derive what the minimum architecture required is. Make a small architecture sketch, outlining the components needed for this story, and then you can break down the tasks accordingly. Your components will move, change, and evolve over time, but that is a good thing. The important thing is to focus on the value, not the system. – Iatrics

So when using kanban, would you add the user stories to the board or the tasks? – Sangria

A bit off-topic, but I'd definitely track stories. You could however design your board, so that when the story is "in progress", it breaks down into tasks that have their own to-do, doing, and done columns, and then regroup when all of the story's tasks are done, and move the story to the next phase. – Iatrics

Answer 2

When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!

Sanctify

Answer 3

A user story describe the what while a task is more about the how.

• There is no perfect formula, just add any task that describe how the user story is going to be implemented, documented or tested.
• Keep in mind that a task should be estimated in hours, so try to scale and detail the tasks accordingly.

If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.

Good luck

Carrion

If there were a system in place already, these user stories wouldn't be all that complex. It's only because we're starting fresh that they become complex. If you already had a car that moved, adding a steering wheel wouldn't be that big of a deal. (just the steering wheel, column, and linkage) It's the fact that the wheels, axle, and frame don't exist yet that makes the story large. – Liberticide

Yeah but still, if you fill like the story is too epic and the subsequent estimation is too large, you should try to narrow the functionalities for the first iterations. With your example you would start with adding a wheel to a mono wheel bike, than adding a wheel to a bicycle with a chain etc, then move on to adding a wheel to a motorbike in the following iteration with a motor powering the wheel etc, than a car wheel into a car with brakes and all, etc... – Carrion

Answer 4

The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.

For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).

If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.

So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.

There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".

Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.

The third story was "As a user I want to define my own filters", and we built this part of the system.

In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.

After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.

To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.

Generator

My only problem with this approach is that it involves doing some work that won't be in the final system: those bits that are hard-coded to represent pieces that haven't been architected yet. I would prefer to always move forward rather than to take steps sideways just to meet the scrum ideal of having a working product at the end of each iteration. But, maybe that's inevitable. – Liberticide

Paul, Its not to meet the scrum ideal. I dont really care about that. Its so that you can build small parts of the system and test them with users and iterate on them. Otherwise you might build the whole whole underlying architecture and then get feedback that involves fundamental change in architecture. This way you can build it up piece by piece. – Generator

Answer 5

I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.

The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.

So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.

In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.

Hoboken

If by "stop futzing" with Scrum, you mean just do it, and improve as you go, I agree. Problem is with "technical stories", you end up doing something that in and of itself has no value. the PO really should invest in learning how to divide a system vertically. One trick is to look at the UI layer and see what is supposed to get done. That is usually your basis for the story. So if you've got a sign-on page, you have a story for signing on. If you're having trouble filling in the as a and in order to parts of the story, you might have a sign that this is not a valuable pursuit. – Iatrics

Well put. I also agree that splitting vertically should be attempted first. But, in some cases - perhaps if this is your first project, and you have no infrastructure - you may need to do some basic things to support every/any feature the system could have. In order to track things better, stories like - install/setup sql server are probably ok. – Hoboken

What I often advise, when starting to develop the first story of the product, is to estimate its size (using story points) during the product planning, as if you just have to add it to an existing system. Then, when breaking it down in the sprint planning, include all the tasks required due to it being the first story, and estimate those in ideal hours. This covers you from all sides: stories are relatively sized, and all aspects of the work needed to complete it are accounted for. – Iatrics