Lately I’ve been thinking about a recurring question I’ve found while planning Agile projects. During estimation, how does a team account for the fact that early work will be more complex than later work?

An example: for the first ‘save’ related story that gets implemented, there is no database interaction layer yet. The next save related story, the necessary save infrastructure should be in place. This brings up some confusion around estimation. The stories need to be independent, but here we have some assumptions that can be made about complexity, based on the order in which the stories are implemented.

The temptation may be to do a couple of things. You might pad all the related stories, such that whatever story goes first has the points needed to account for needed implementation details. One could also try to track dependencies within each story, which would be complicated. Another thought might be to re-estimate the stories in real time, depending on which story comes first at implementation. The problem with those strategies is that you add complexity, increase overall risk, and make the total representation of effort inaccurate, which in turn lowers the accuracy of prediction.

As it turns out, the answer to this question is pretty simple. It was Mike Cohn (surprise surprise) who made the point that had me slapping my forehead. In most work, there will be a ‘natural’ order, so it’s implied that some work must be completed before other work can take place. An example of this is comparing an ‘add’ story with a ‘delete’ story. Except for some special case, it makes sense you will need to add things first. Otherwise, you have nothing to delete! So, where tracking a dependency manually would become tedious, tracking a natural dependency should be, well… natural!

Keeping natural order in mind, it becomes easier to guess which stories will encounter the additional complexity of heading into untouched areas of the project. This order is probably natural enough that it doesn’t need to be called out while setting priority during release planning. However, it would be wise to keep it in mind, especially during estimation. Should the customer decided on a priority that runs counter to a natural order, they may need to be made aware of a need for estimate changes and any additional effort the new order will cause. In these cases, it should be fairly painless to shift estimation weight within the affected stories, without upsetting the overall representation of work load.

In addition to the natural order principle, there are additional practices for story writing that work to balance out estimates, making it less necessary to manually shift load between stories. One is to be strive for each story to cover a full ‘slice of the cake’, meaning it represents a vertical path through all layers of the solution (UI, logic, services, whatever). Taking time to triangulate estimates will also help the stories be balanced, further keeping the total effort accurate.

In the end, velocity should make up for variations in estimation. As the project goes on, stories that run over their estimate are likely to be offset by other items that take less effort than planned. In addition, you may have a stretch of better than ideal days, or a hairy integration will go without a hitch, which will counter those problem stories. Another way to ‘make up time’ is to keep your code quality high. The later that fixes occur in development cycle, the more time consuming they become. That’s an entire subject in itself, but information on the link between productivity and quality is not hard to find.

A final thing to keep in mind is that there is a fairly constant level of ‘additional’ effort in most projects –it’s just the form of that effort shifts as the project goes on. While later stories may lack the difficulties around a new aspect of the design, the later sprints and stories will likely include the need to refactor, add missing tests, or apply fixes. Again, these forms should balance out, keeping estimates on par, regardless of implementation order.

 

Comments are closed.