Compile A Document As You Are Developing

Doing your Business Analysis? Make your notes in this document. It doesn't have to be pretty, treat it as a jotter.

Got your 'To Do' list sorted? Jot it down here until you have compiled your skeleton unit tests.

Something pops into your mind about a scenario you should consider? Jot it down quickly and stick with the flow of what you are doing.You can think about this new scenario later.

You've just discovered something that will be useful for the testers? Jot it down... You can transpose it to the Work Item later.

This document can give out a lot of things, all of which impact directly or indirectly on the team's velocity:

• It means you know where you are with a WI. If you have to break off and do something else for a few days, jot down an entry point that will help you quickly get back your brain back into the right space...
• It can help you maintain your flow even when your brain is throwing stuff at you that is not to do with the flow you are working on
• It can help you give more accurate estimates of how much is left to do on a WI
• It can improve the quality of the documentation you leave behind you, making subsequent stages flow more quickly. You will find stuff out about the domain as you write your code. You will consider different approaches and come down in favour of one - the one that ends up in your code. You will identify scenarios that are so unlikely to happen in the real world business flow that it is not worth the effort to add in code to cover those scenarios. You will find ways of setting up data that make it easier to test your new functionality.
  
  If you document all of this stuff concisely before you pass your Work Item on for peer-review, you will save the reviewer a lot of time. If they are a good reviewer, they will think about other possible ways of tackling the problem you have solved. If they can see that you have already considered those options, and the reasons you discounted them, it will save time.