One of my favorite ways to make sure my projects are well rounded is to look at the past, the present, and the future of the project, and make sure all 3 areas are being thought about constantly.
Imagine you’re onboarding someone onto your project. How would you explain where the project came from, where it is now, and where it’s going?
The past: project history
Key artifact: living documentation
What is the past of your project? Maybe it’s just getting started, in which case the past is just the history of the initial conception and the product vision, or maybe the initial talks with the client. Or maybe it’s been going for a year, and we have thousands of lines of custom code and lots of functionality.
To have a robust project history, the key is documentation. How did the deal come about? What is the product vision? What was the initial architecture plan, and how has that changed over time, and why? What are the major tradeoffs we have had to make? What are the big problems we have had to overcome? What has our average velocity been over the past few months?
This is all gold, in terms of onboarding. Being able to catch someone up with “how we got here” can save a lot of time of trial and error on onboarding, and that’s impossible to do unless you have living artifacts (i.e., documentation).
The present: current status
Key artifact: backlog and sprint board
Where are we now? What is done and what isn’t done? What’s in progress and what is blocked and what is on hold? How many points did we plan for this sprint, and how many of those are complete? All of this stuff should be clearly visible at all times in the backlog and/or the sprint board.
This tends to be the one that most teams are already doing (who doesn’t have some sort of Todo/Doing/Done board these days?) so I won’t harp on it.
The future: project planning
Key artifact: architecture document and milestone timelines
Where’s the project going? Where do we think we’ll be in 3 months, vs. 6 months? When can we launch, and what will we be launching with? What still needs to be built, and how are we thinking we’ll probably build it?
All of these questions should be answered, in writing, at any given time.
The technical answers (i.e., “how might we build X?”) should be answered in the project architecture document. Yeah, I hear you shouting that you don’t want to plan out an entire project’s implementation ahead of time, and you want to allow developers to create their own implementations as they start tickets. But the really big pieces, the big scary risk-prone things, those should have planned implementations that are talked about early on so we all agree that they’re even possible in the timeline. That belongs in the arch doc.
The timeline and process answers (e.g., “what will go into the next milestone and when will it be ready?”) should be mostly answerable using whatever ticketing software you’re using, which should be tracking either average velocity or average cycle time so that you can have a rough idea how long it’s going to take to get through the X tickets you need to complete for the next milestone. And then you’ll probably want to have a separate milestone doc that makes all of that information cleaned up and easily readable.
The full picture
There it is. The past (documentation of the history of the project), the present (current status of the work) and the future (architecture plans and timeline) should all be up to date in writing, easy to find, easy to read, and easy to understand by anyone, whenever.
Take a second and think about your current project. Do you have the PPF well covered? Which part are you most lacking in? Which part would be the hardest for a new person on the project to quickly wrap their brain around? Work on that thing. You’ll end up with a more robust project that is easier for people to onboard, and you’ll probably end up realizing there are things you hadn’t thought about that will change your approach a bit.
Try it out!
Mike Crittenden 