The burndown suffers due to “technical” dependency between tasks - should we focus more on each task, and accept additional overhead?

Question

We have a new piece of functionality coming up. It comprises of 9 different user stories, covering the functions needed. Three of these are listed below:

• As a user I should be able to add a person so that...
• As a user I should be able to edit a person so that...
• As a user I should be able to delete a person so that...

These three issues make out about 20 sp's each.

The challenge is that these three issues are in practice treated as one issue. So, instead of having a nice burndown with 20 sp's burned on Tuesday, 20 sp's burned on Thursday and 20 on the following Monday, I get to see 60 sp's burned on the last day (e.g. Monday).

In theory, (I believe) this is wrong. Each issue implemented should be "atomic" in the way that you can deploy this in production once the issue is done. This makes sense, and in my scenario above, you can deploy "add" to production without having edit and delete.

However, from a technical perspective, it makes sense to "combine" the implementation of the three. Or at least add and edit. They share a lot of logic, and you might have to "pay more" if you first complete "add" and then start on "edit" the day after.

Question is if we should continue as this, and have a rotten burndown in these cases, or if we should allow for more overhead and focus on the theoretical part - e.g. "atomic" issues.

Or should we consider something else?

Answer 1

The best thing to do would be to stick to the atomic nature, i.e. working on one user story at once instead of all at the end.

Doing several related but atomic stories at once can have several problems. It makes testing more difficult and takes more time, as there can be a dip in stories to test, then a sudden flood, leading to irregular test workloads. It also means that finding which story a bug relates to becomes more difficult.

In your example however, this is not always possible. The story to add a user would most likely have to be completed prior to the other two stories, as it would be difficult to debug the editing/deletion of a user without being able to add one.

Answer 2

The significance of atomic stories is that your application should be in a state that can be deployed after a story is completed: build is not broken, all tests pass, etc. That does not mean that your application at that point is feature complete, it just means that a single story is finished but the feature as a whole does not necessarily work yet. Would you really WANT to deploy add without having edit or remove? Probably not... You deploy when a FEATURE (which can be comprised of multiple STORIES) is completed. Sometimes 1 feature = 1 story, sometimes 1 feature = 12 stories.

Atomic stories also mean that multiple stories can be worked on simultaneously, which is important in bigger teams. In that sense, add and edit cannot be considered atomic because they depend on each other. Nothing wrong with that, and also nothing wrong with writing the code for your first 'add' story taking the fact into account that you need to do an 'edit' story next.

For these kinds of features, we often have estimations that are heavy on the 'add' story. In this story, we create database tables, create new domain objects, new pages, and so on. The 'edit' story is a lot less story points because we already have the tables, object, pages and so on. We factor this into account when estimating.

Concerning your burndown: you don't draw a burndown based on storypoints. Unless you are doing hundreds of stories in a sprint it makes more sense to burn down based on tasks. Stories are estimated in story points to indicate the amount of work a team thinks it will take which allows some amount of planning ('how many stories can we fit into a sprint'). Teams then divide stories for a sprint into tasks and burndown on those. You can burn down on story points when you are doing things like a yearly status report.