User Stories & Tasks - Agile tasks granulation concept. Can it bring some value?

In this post i would like to share with you agile tasks granulation concept with some ideas how it can be used – and with some open questions that bothered me. Simple (?) questions that were result of my lack of experience in this matter.

According to Agile practices we can use following granulation:

User Story - Description of desired functionality told from the perspective of the end user
Epic - Large user story that can be broken up into several smaller user stories , to reduce uncertainty
Theme - Group of related user stories (or/and epics)

In one of my projects, we were using jira tool with many kind of tasks, tasks like bugs, features, change requests, etc… requirements were not always strict user stories & we were fine with that for some time, but … we hade some problems with Definition Of Done (DoD). Usually tasks were finished at the end of the sprint, but actually it was only implementation, since tests were usually in last phase before release (so sth from waterfall rather then from scrum). Another problem was that tester was not from the start with the team & he had problems with understanding some tasks since most of them were technical (useless in his eyes). We hade many obstacles that we were working on so …

So there was a time when some questions appeared in the team.
Questions like:
- Can we make our planning steps easier?
- Can we approach more closely to Definition Of Done?
- Will it make our client happier ?
- Will it make us as a team happier ?
- Is it a place were we could use this strange agile approach to tasks granulation? Can it bring some new value for us ?

After some thinking proposition of extending DoD in our Project occurred.
Extension? Or maybe we just narrowed a little bit our version of DoD?

Well, the base idea was: Try to get at the end of the iteration/sprint done & tested user stories, implemented but not tested tasks is not enough! If we don’t know if we can or should use all granulation entities, make it simple. Use small fragments. Don’t use theme or epics if you don’t catch the idea or think that it is not necessary. Adapt this solution for your project! Remember that this is the first step of improvement - we don’t want to take to much at our shoulders (since we are new in this). Start with something small that can be useful. Something that will make team vision & business vision more & more coherent during every iteration.

Well, i need to get to the point finally. First I will explain what was done exactly & then I will try to point out what benefits came out from this solution.

1. Let say that we get some requirements from client in form of user stories (which was not always true, but we tried to wrote them as user stories):
   
   
2. Now let say that our first 2 stories were to big to start development or just to think about them in scope of tasks with some estimations. What we will do with such stories?
   
   
3. Simply, we should rename those (to big) stories into epics & divide them in smaller stories. Just enough to produce some tasks from them & finish such story in one iteration (ideal).
   As we can see Story 1 became Epic 1 & was dividedinto Story 1.1 & Story 1.2. Same thing happened to big Story 2.
   
   
4. Next step is simple, when we have small user stories, we can divide them into concrete tasks. If some tasks are to big, divide them into sub-tasks, or just use only sub-task level if your tool doesn’t support creating children for tasks (1 level tasks only).
   
   

If we are using tools like Jira with Greenhopper, we can do one more thing. Since this tool allows to define connections between Story/Epic/Issue & tasks we can set it up during stories creation & use it later to easily see:

• Listing of issues per Story
• Listing of Story per Epic
• Epic/Story statistics (how many issues, how many stories, ect.)

This part is not ideal in Greenhopper (yet), but it fulfill its purpose.
(For details go here: http://confluence.atlassian.com/display/GH/Working+with+Epics)

Of course last step is sprint planning with assumption that unfinished user story should be moved to next sprint (we would like to improve DoD).

I hope everyone see benefits of such solution:

• Easy to manage shared feature functions or some tech. design
• Tester gets complete user stories for tests, without all this technical mess…
• Since User stories bring business perspective into play, every iteration makes team vision & business vision more & more coherent
• What i salso interesting, the whole team is more aware of Project purpose & it’s capabilities from business point of view. Understanding is spreading much faster.
• and what i mentioned before, if we use some tool that can link epics-stories-tasks then we can easily know with what stories our task is connected (2 stories can have same technical task as part of their solution), we can easily check what kind of tasks are/were linked to bugged user story, etc…

So theory is very nice & it actually can help a lot i think. Such simple thing but so much advantages in many aspects of project.

So yes it looks nice but implementing this idea create different problems, or rather questions about the way how we could use it.

For example - we now what should we do with user story. But what if such story is very simple? Should we create artificial 1 to 1 relation? One user story (where we can add business value parameter for example) connected to one technical task (were we can track technical design & estimations) ? Just to be strict with Agie granulation proposal? Or maybe if we don’t track parameter like business value, we should just create user story without technical task?

Another thing – what is if we had some change that is not direct user story (non-functional requirement). For example change label from… to… . Probably we get this requirement in different form, with some explanation why we need this change. Then it would be sth like user story. But still, should we create task for this? Or user story for task? After talking with my colleague, I thought that it would be good to collect such small changes into small packages. So we could have one artificial user story with few label changes described. Then we could create one or more task for this user story, depending if we would like to delegate those task to one or more team members.

Aditional question is how we can handle it on task board? should we place story with all tasks together? so if Story is divided into 3tasks. we are starting implementation (in progress) then we are testing them & closing as tested. Should we move Story to in progress state when we are implementing one of those tasks? or rather wait till they all will be finished (tested, DoD) & then
move such Story from New state directly into done state ?

I'm still wondering about those small things...

So this granulation approach can bring much value, but the question is how we can adapt this method. Should we do it strict? Or maybe it would be wrong idea? Maybe those questions are not so hard to answer.

Some additional reading:
http://www.infoq.com/news/2011/04/how-to-split-user-stories