1

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?

sonstabo
  • 113
  • 4
  • 2
    It's not clear to me if "issues" are the User Stories themselves or Tasks, i.e. smaller work items describing how to implement a story. If you have Tasks, they should definitely be reflected in the burndown, User Stories shouldn't. – guillaume31 Oct 23 '15 at 09:59
  • For us, the examples above are user stories. And one one of these are done, points are burned. – sonstabo Oct 23 '15 at 10:42

2 Answers2

2

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.

FLSH
  • 159
  • 1
  • 6
  • I'm in favor of atomic tasks. But my team lead is worried about the overhead, e.g. that you might have to change some of the code related to "add" when you start coding "edit". Devs test themselves, so the task is only done when tests are complete. QA do exploratory testing most of the time. – sonstabo Oct 23 '15 at 09:56
  • 1
    It's inevitable that one user story will lead to changing work from another user story. If that didn't happen, files would be checked in and never touched in their life again? – FLSH Oct 23 '15 at 10:00
  • Yes, I can agree on that. It might be more related to the amount of changes? If you write a total of 1000 LOC to complete an issue today, and you know you have to rewrite 20 % of them over the next 2 days as you start on another related issue, I can see that it makes sense to do them both at the same time. Is this amount of change an indicator of bad design, or the overhead that we must start to accept? – sonstabo Oct 23 '15 at 10:04
  • These tasks look too fine-grained to me. Shouldn't the story be "user management", and the tasks be "add x, y, z DB table", "design new GUI page", "update manual" and so forth? We break down stories into tasks, not sub-stories. – Lightness Races in Orbit Oct 23 '15 at 10:10
  • 1
    @sonstabo That's somewhat to be expected, refactoring is an integral part of continuous integration. That said, if something is identified that you believe will require a large rewrite of a story, this should be completed as part of the story so that the modifications go in as the original code. – FLSH Oct 23 '15 at 10:46
  • @FLSH; then'we are back to my discussion with the team lead earlier today - should add/edit/delete be added to the same story? The burndown will still look like crap (60 points are burned instead of 3*20, but still at the same time), but it might be easier on the team (deal with one issue instead of three separate ones). – sonstabo Oct 23 '15 at 11:04
  • @sonstabo - That's probably why they all have 20's because they're going to average out when you have to go back to fix the add function because of something you discovered during the the edit. – JeffO Oct 23 '15 at 20:09
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.

JDT
  • 6,302
  • 17
  • 32
  • Some teams don't do tasks at all (see http://www.allaboutagile.com/burndown-user-stories-rather-than-tasks/) that's why I was more cautious in my comment above. But yes, if you do tasks they should definitely be in the burndown. – guillaume31 Oct 23 '15 at 10:18
  • @guillaume31; we do not do tasks, only user stories. And they are estimated in sp's. In regards to the link, there might be a clue in the section regarding "user stories are small". I recon they might be to big now, but as you see further below, @ Lightness Races in Orbit believe they are to small. – sonstabo Oct 23 '15 at 11:00
  • @JDT; we usually have between 75-100 issues (user stories, bugs or improvements) per sprint, all estimates in story points - so yes, we burn these per sprint. My challenge is the burndown as such - the team is able to deliver everything in the sprint, but the burndown is very much "off" from the guide, which again raises a lot of questions from people that are outside the team (read: mgmt). – sonstabo Oct 23 '15 at 11:02
  • In that case, I'd assume your estimates are wrong. If you split user management into stories I highly doubt that 60 points total would divide evenly across 3 stories. I'd expect something like 35-15-10 or the likes, which would still seem odd but would easily be explained as 'first story needs to put the basic structures in place'. – JDT Oct 23 '15 at 11:09
  • @sonstabo The stories you mentioned in the Q look like the right granularity to me. But 75-100 issues per sprint does seem huge - do you manage to go through all of them in end of sprint demos ? – guillaume31 Oct 23 '15 at 11:11
  • 1
    Actually, I somehow get the feeling you are using your burndown on the wrong numbers. If you want to indicate progress in a sprint, you need to burndown on 'things that can get done today'. The guideline gives you an indication of how many points of the total you should be getting done each day. If you track progress only when stories are finished, your metrics will always be off. Either burn down on the NUMBER of stories done, or the number of TASKS done. Don't burn down on the number of (estimated) points done... – JDT Oct 23 '15 at 11:15
  • @JDT; my representation is a bit wrong. Add is 26 sp's, edit is 20, and delete is a fabrication . We would not delete, we would deactivate/archive someone, and that is part of "edit". I included delete more as an example (which might have been wrong). So I guess the estimates make sense in that regards. I do not believe that this changes much though? My burndown is still skewed as the issues are developed in parallel by the same dev. – sonstabo Oct 23 '15 at 11:19
  • 1
    Oh, in that case don't do them in parallel. Do them one at a time, but take the other stories into consideration. For example, if you add feature needs to assign data to a user object ('name' textbox to 'name' property, 'gender' dropdown to 'gender' property) you know that the edit feature will need this, so put this into a method. Your dev should work on a single story, but code everything knowing that the other stories need to be implemented too. In that sense, your estimates will be heavy for the first stories but that's just the way things are... – JDT Oct 23 '15 at 11:25
  • That is my "take" on it as well @JDT, and what I intended to describe as "atomic" issues: Every issue should be implemented in a way that makes it possible to deploy them to production immediately after the are completed (disregarding if they make functional sense or not). In this case, it would burn down the sp's as we move forward, instead as one big chunk in the end. Btw. our "way" of doing things is very much a flavor of Atlassian: https://confluence.atlassian.com/agile/jira-agile-resources/jira-agile-faq/how-do-story-points-get-burnt-down-and-reflected-on-the-burndown-chart – sonstabo Oct 23 '15 at 11:32