Agile methodologies, like most flexible yet powerful systems, rely on knowing exactly where things stand. You may not know exactly what’s coming in the future, but you know what you’ve already got, and roughly how close work in process is to done. This is one of the many reasons short iterations are a good idea. Not only do you know on a frequent basis (the end of each iteration) where you stand, but if what was done is acceptable to the stakeholders (and QA) and can really be considered done. The product backlog tells you what needs to be done in the future (based on current knowledge, which may change, and that’s OK) and the iteration backlog tells you what’s done and what needs to be done now. The burndown chart shows how things are going inside the iteration.
Tag: Project Management
I came across this blog post on the Developer Art blog on preserving and sharing project knowledge. I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.
This is a topic near and dear to my heart. Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times. They can lead to information overload, but to me, it’s worth the risk. You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them. I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact. The act of recording the information also helps me remember it.