User Stories Vs. Tasks

User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

A Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.

Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.

In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.

Writing stories should be a separate activity from the tasking of the stories themselves. The story should be about what specifically you want your product to do and clearly explain the value of this feature. Together with the scrum team you should clearly define the acceptance criteria of the story. Only after these are defined should the story be tasked out by the contributors who will be doing the work. They get to decide how to best get it done.

The process of breaking down a user story is important because it helps me think about how I'm going to build the functionality. Many people disaggregate a user story into tasks and then estimate them (usually in ideal time) because they're smaller units of work and can be estimated with less inaccuracy. Then they total the task estimates to obtain a better indication of how long it will take to complete the user story. Tracking each task's remaining time feels like micro-management, so I don't it anymore. I'm only interested in tracking the number of running tested features. I want to know how many user stories are passing all their FIT tests.

~SA

Agile estimation – Story Points vs. Hours

The most common debate (or rather, amusement) between software engineers in an agile team - hours (or days) and not story points are a better way to estimate user stories. I disagree.

Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.

Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.

Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.

Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
where
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge

Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.

On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.

Finally, if I hear someone say that they have a capacity of 200 real hours, that they’re signing up for 300 hours of work and end up completing 250, then in my mind, the 250 hours of work that got done (which can’t be squeezed into 200 real hours) might as well be 250 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 200 real hours (time doesn’t change), they signed up for 3000 points and got 2500 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…

~SA

Instant Gratification To My Dear Pa

It's true what everyone says. When you lose someone who was so close to you, and so involved in your life, the pain never really goes away. I lost my father last month, and I still feel like he is on a perpetual vacation. He was very nice person, not an alcoholic, was not abusive, and was not a bad father. He was actually the best father he could have been. He loved me so much & i loved him too.

There is not a day that I do not think of him or wonder what he might think of me if he were still here; but by taking the best of his qualities and learning lessons from his life, I like to think that I have kept the flame of his spirit dancing within the halls of my own being. In that sense, he has never left, and he will continue to accompany me during the remainder of my own limited time on this planet.

Thanks Pa for giving me life & everything in this life. I'll miss you always.