Agile Zone is brought to you in partnership with:

Mike Cohn is a consultant and trainer who specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He is the author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. He can be reached through his website at Mike is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

Estimating Work Shared Between Two Backlog Items

  • submit to reddit

Product backlog items can be ideally written to be independent. It is the hallmark of a good team that its members can implement product backlog items in any order. However, it would be nearly impossible to remove all dependencies between product backlog items and so our goal becomes minimizing important dependencies rather than eliminating them altogether.

But any dependencies that remain can raise questions about how to estimate the individual product backlog items. One common question is what to do with work that could be performed as part of either of two backlog items but that only needs to be done once. As an example, consider these two product backlog items, which are written as user stories:

  • As a user, I can add an invoice to the system so that it gets paid.
  • As a user, I can delete an invoice.

These two user stories share some work. Supposing this is a very simple system, whichever one of these stories is done first will also involve the team much of the database design for invoices. Some database design work (a cascading delete between Invoice and Line_Items, for example) will be done only when a specific one of the stories is developed. But, some work (deciding that a table called Invoice exists at all, perhaps) will be done as part of whichever story is implemented first. Assuming that this work is non-trivial, the estimates given to these stories will be influenced by which will be implemented first.

In deciding how to estimate these and how to handle the common work between them, I suggest there are two guiding principles we can rely on:

  • We should assume work will be done in its natural order.
  • The sum of all estimates on the product backlog should represent the total size of the project (as understood at that time, of course).

Let’s see how these two principles lead to the answer about how to estimate our two user stories about adding and deleting invoices. Although a good agile team should be able to implement these stories in either order, it is most likely that the product owner will ask the team to add invoices first. After all, you can’t delete an invoice until it has been added. This is what I mean by the natural order.

Although it is natural to add invoices to a database before deleting them, it is not hard to imagine a need to do these in the opposite order. Suppose our team is writing a new system to interface with an existing invoice database. That existing system is full of old invoices from the 1940s and the first thing the product owner wants is the ability to delete old invoices.

When a product wants stories done in the natural order or when it seems likely the product owner will want them done in that order, my advice is that the team should estimate with that assumption in mind and not bother noting it on the story cards. Documenting all logical assumptions about the natural order gets tedious. To document all such assumptions, our add an invoice story would also need to be documented with “assumes login story is done first,” and so on.

But when a team knows or suspects they will be asked to work out of the natural order, they should document the assumption. If the team assumes that adding an invoice will be quicker to implement because deleting is already done, they should add appropriate notes to these story cards.

Teams are, of course, sometimes wrong in their assumptions or are surprised by product owners who change their minds. These situations are resolved by simple discussion along the lines of saying “We assumed you’d want these stories in a different order. So, a few points [or ideal days] of work move off this story and onto that story.”

It is even possible that working outside the natural order can sometimes increase the total size of the work. For example, to do the delete invoices user story before the add invoices story, our team might need to write a short script to preload the database with dummy data just so we can be sure delete is working. Usually when this happens the change in project size is very small and washes out in the noise of other estimating and planning errors. (In other words, it’s rarely worse than someone being out sick for a day.)

Why not get around this problem of potentially moving points from one story to another by assuming that each story is done first, which would be a worst case for its estimate? This is where our second principle comes in: The sum of the estimates should add up to the total size of work being considered. If the total work is 8 and that’s what we’d put on a single add+delete user story then our two user stories need a total of 8. To put a higher number on them overstates the size of the project. This would lead to incorrect projections of the project completion date based on velocity.

Published at DZone with permission of Mike Cohn, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Emma Watson replied on Fri, 2012/03/30 - 6:02am

I agree with your observation, I also think when in the hands of experienced analysts those dependencies are easily identifiable and presentable as valuable things to do in their own right.

Does the technical task in your example do something in addition to creating the very object we want to manipulate in some way, in this case add or delete?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.