2

Scenario: Let's say there are two items A and B in the product backlog of a Scrum team. From a PO point of view B has more customer value than A and is therefore ranked higher. When asking a developer for the estimated time to work on these items he gives the following input:

  • A takes 2 days
  • B takes 2 days; but if A is done before then B only takes 1 day (as some prerequisite work is done in A as well)

This means that, when B is done first and then A, the overall time for those two work items is 4 days. But when A is done before B the overall work time will be 1 day. But this will be against the priorities as B is ranked higher than A.

Please assume that both work items cannot be completed in the same sprint. Otherwise, there is no need for this question :)

Actual question: Should estimates incorporate such information?

Our thinking: We've been discussing this yesterday on whether the estimates for work items should keep this in mind. Should a PO have this information to reorder the product backlog based on this information? We came to the conclusion that estimates should not contain this information, i.e. B takes 2 days time, period.

The reasons for that are:

  • The product backlog is ordered based on customer value
  • When B shares a task with A, what about the other items? There will probably be more tasks like that that need to be looked at. This will lead to long lasting discussions without a reliable result.

Are we missing sth. or is our thinking correct? There are probably more reasons to add to that list.

3 Answers 3

2

I would say that your thinking is correct.

Your estimates should be based on the currently existing codebase and not based on "what if" scenarios. In your example, Story A may never be completed and it would continue to get pushed down the priority list as new information becomes available.

On top of that, it would also stand to reason that doing A before B makes B faster because groundwork is completed that doing B before A would make A faster because of that common groundwork.

3

Ideally backlog items are independent of each other, in which case this question would not arise.

Where there are technical dependencies then it is down to the development team and the Product Owner to decide on the best approach.

Some things to consider when deciding on an approach:

  • If a higher value item is moved later in the backlog then the time it starts to deliver business value will also be delayed. It is up to the Product Owner to decide on the impact of that delay.
  • It is usually better to have delivered value than work in progress. Hence delaying delivery of value to increase the overall efficiency of delivery can sometimes be a mistake.
  • The efficacy of starting on item B before item A assumes that both items will get completed. There is always the possibility of a change in priorities and item A may not get done as a result.

It is worth remembering that the Agile approach emphasises optimising delivery of business value rather than optimising the efficiency of development.

These two things may sound the same but when responding to change they may not be. It is sometimes more effective to make compromises on the efficiency of development in order to more quickly respond to change.

2
  • I just updated my question as I wasn't clear enough about dependencies. Sorry for that. I'm actually not talking about dependencies but shared tasks/prerequisites (kind of).
    – Stephan
    Commented May 20, 2016 at 12:00
  • 1
    That can be awkward. For example when working with business reports there is a lot of plumbing before the first story is completed. The teams I have worked with have typically had a 'bootstrap story'. That is a story that provides a small amount of business value (say it provides one minor measure on a report) and that story ends up being quite big as we anticipate putting a lot of the plumbing in when completing it. Subsequent stories are simpler and so end up having smaller estimates. Even this approach is questionable. The danger is we end up with stories that cannot be done out of turn. Commented May 20, 2016 at 12:53
0

We would decide this in the sprint planning. If B really depends on A, then the answer is easy.

If A being done makes B less "painful", try to put them in the same sprint, keeping that in mind and reducing the effort for B accordingly.

So yes, the dependecy would be incorporated into the estimation, IMHO.

If A and B remain equal... well, do whatever you like.

1
  • I just updated my question as I wasn't clear enough about dependencies. Sorry for that. I'm actually not talking about dependencies but shared tasks/prerequisites (kind of).
    – Stephan
    Commented May 20, 2016 at 12:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.