Shared Development Tasks for Agile User Stories

Question

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?

Answer 1

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.

Answer 2

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.