My team is going to be using Visual Studio Team Services for an upcoming project. The Agile tools let me organize User Stories and Tasks hierarchically like this:

Epic > Feature > User Story > Task/Bug

Let's say that I am designing a Student Org (club) management system for high school students and advisers. Students and Advisers can join clubs, be officers, organize events, send announcements, etc.

Let's take the Announcements feature as an example:

User Stories:

  • As a Student, I want to read Announcements for the clubs I am a part of so that I am aware of schedule changes.
  • As an Adviser, I want to read Announcements for the clubs I am a part of so that I am aware of schedule changes.
  • As an Adviser, I want to send Announcements for the clubs I am a part of so that my Students will be aware of schedule changes
  • As an Administrator, I want to send Announcements to ALL school clubs so that I can make them aware of scheduling conflicts.
  • etc

If we assume these are well-written User Stories (which they might not be), I get confused when my development team and I sit down to split these items into development Tasks. We can cover parts of several User Stories with single development Tasks. For example, we have a tool that generates CRUD actions for all of the layers from UI to DB simply by defining the properties of an Announcement. So, the parts of several "send" and "read" User Stories are completed in a single development step.

From what I've read, each User Story should be independent of the others and that makes sense. But each of our User Stories shares the "Generate UI and DB" Task because this is how we create our base-level UI (before we customize it). I shouldn't write a "Generate UI and DB" Task for each User Story. That's too much redundancy. But I don't know how to write a "Generate UI and DB" task that must be completed before any of the User Stories can be started.

I have similar confusion with our permission system. We have different account types like Student, Adviser, and Admin that all have access to the Announcements page, but have different functionality within the page (I captured this idea with the User Stories above). We can write the permission system to be modular so that it can be used for other Features, but I don't know where to write the Task to create a "modular permission system".

I guess this whole User Story thing has me confused. Yes, it's great for capturing functionality of a system, but when it comes to thinking through development Tasks, I can't seem to wrap my head around it. Any advice would be great.

TL;DR: Some of the programming I do for one User Story can be used elsewhere in our project for other User Stories (permission system, etc). How do I write/organize Tasks for User Stories to illustrate this possibility?

2 Answers 2


I shouldn't write a "Generate UI and DB" Task for each User Story. That's too much redundancy. But I don't know how to write a "Generate UI and DB" task that must be completed before any of the User Stories can be started.

You don't.

You write your user stories as high-level user needs - you've gotten that far.

Then you pick the user story (feature) that you're going to tackle first. At this point - given the current state of the product - you decide how best to implement this feature. Then you do the minimum technical work required to implement the feature. Then you move onto the next user story.

This might work out as follows:

  • We sit down to do user story 1 and identify that it requires a database. So we implement the database and then the feature.
  • We sit down to do user story 2 and identify that - hey - we already have the database so now we just need to extend the UI.

Or in your example it might even work out as follows:

  • We sit down to implement sending an announcement. We build a UI with a text box and a send button that makes a form post. Back-end, nothing happens. Cool. User story complete.
  • Now we sit down to implement receiving announcements... guess it's time to start doing something with them when they're sent.

The whole purpose of this process is to stop you from trying to design the whole thing up front and allow you to make informed decisions about how to implement the next thing given the current state of the software. That is directly incompatible with trying to break all the stories down into technical tasks before starting any of them.

So you only design the solution once you pick up the story and you evolve your design a feature at a time. How (and even whether) you document your technical design once you start work on a story is up to you.

If two developers pick up two stories at the same time and they both share technical requirements, that's telling you that you can't do those pieces of work in parallel, so pick one and have the other dev do something else.

The purpose here is to implement simple solutions and revise your design as new requirements emerge.

And, most importantly, remember: this is not a science.

  • +1 for "database stuff exists, let's just extend the UI." Our team did this exact thing earlier this morning, actually. It just means the story with the common stuff is a bigger story. Most likely it will be more story points than subsequent stories, unless the testing effort is larger. We had 1 "common stuff" story that ended up being 13 points. The next story was basically doing a smidgeon of database stuff, and extend the UI. It was also 13 points. Less development, but we identified many more test cases. The last story was much less than the other 3, because of fewer test cases. Commented Jul 19, 2018 at 18:31
  • I was treating User Stories / Tasks like a more "formal" Waterfall methodology. I was trying to think through and write out all of the Tasks needed to complete each User Story before development even started. I didn't understand the fundamental concept of Agile as being "pick a story, determine the tasks, implement, repeat". Agile makes more sense now, thank you!
    – Schmidty15
    Commented Jul 19, 2018 at 18:40
  • 1
    @Schmidty15: I did the same thing before too. And ran into the same problems. Treating agile like waterfall just means you encounter the same problems that come with waterfall development, except more frequently. Commented Jul 19, 2018 at 18:51
  • 1
    @Schmidty15 my (old) team used VSTS much like you are. We would not have even used tasks if we hadn’t a need for ISO-9001 compliance. We created tasks on the fly just prior to implementing the task solely so we had a way to track each commit back to a “requirement”. It was a convenient way for us to avoid the “I don’t have a work item for this refactoring” trap. Just food for thought. You might not even need to track the tasks at your shop. You may want to do it just in time for traceability purposes.
    – RubberDuck
    Commented Jul 19, 2018 at 21:30
  • 1
    @Frayt: you wrote "User stories should be written from a user perspective with no technical information." . Strictly speaking that may be true, but user stories aren't necessarily the only type of item on the product backlog. You can have other types of stories. Commented Jul 25, 2018 at 12:09

Given that you are entering each sprint with a prioritised list of stories, and each story is broken down into separate technical tasks, all the developers should be working on tasks for the highest priority story before starting work on the second highest priority story. Because of this, by the time you start work on the second priority story, the 'Generate UI and DB' task should have already been completed as part of the first story. So, if during sprint planning you find that one technical task is duplicated across several stories, attribute that task to the highest priority story so that it will be completed first.

If your team has a habit of re-arranging story priorities once the sprint has started, you may see benefit in including duplicate technical tasks on each story, and making a note on the task of which other stories use it.

It may help to get into the mindset of working from a list of technical tasks instead of a list of stories.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.