Early bird misses the bug

For teams doing Agile, there is often a push to get ready for implementing a story early – long before the story is scheduled for implementation. The prep work is often way beyond getting the basic understanding of what the story is about, and sharing the vision for the result. It involves delving deep into the technical details and complexities, code minutiae, architectural and environmental setup.  By gathering that intelligence early, the team tries to minimize the risk of uncovering additional complexity of the story and missing estimates when this story is finally scheduled into the iteration.

The intentions are good – having more details early seems more prudent, being knowledgeable about the story beforehand gives the team more confidence in providing estimates, and PO feels that she is doing a good job communicating with the team about future stories.

However, there are problems with pre-preparing stories ahead of time.   

For one, the team is pushed to work on stories that are not in the current iteration.  This work has no definition of done, no acceptance criteria, and pulls the team away from working toward current iteration goal.

A bigger problem is that once all this work is done, the story is about as likely to go into an iteration soon, as not. The intelligence gathered may get written up or not, but even if it is, this knowledge is still very perishable. If the pre-worked story sits on the backlog even for a couple of iterations, much of that intelligence deteriorates beyond any usefulness.

The biggest problem with pre-work, though, is the pressure it creates. Pressure to create exact estimates, since all this work has been done on the story beforehand.  Pressure to not ask questions later on, when the story is actually being worked, since the onus is on the team to ask questions early.  Pressure to burn the midnight oil, if the story turned out to be more complicated than expected, despite all that time spent researching it before.    

One of the rules in eXtreme Programming is “Keep the system uncluttered with extra stuff you guess will be used later”.  This is also a good rule to plan work by.  Do not pre-work the stories, let the team ask the questions and use the answers immediately, as they are working the stories in the iteration. It is OK to take the risk that sometimes some stories will turn out to be more complex than others, and will need to be continued in the next iteration.  Overall productivity will be higher, because the team will spend less time on work that is not moving the team closer to the iteration goal.  Overall quality will be higher, because the team will have the latest information available, obtained at the last responsible moment, and will not have re-research outdated intelligence.