I'm thinking about how to improve the transparency of our planning and the accuracy of our planning message. I think the bulk of the real planning is happening now in the design docs. Which is exciting. This is something that works, gets updated, etc... I see the design docs as the master data for any planning transparency and also for our public roadmap (which is stale and far from up to date at the moment).
Before I share my thought on the roadmap I would like to discuss the evolution of the design docs. Very often a design doc contains many stories which we will implements step by step. Some ideas in the design docs will never be implemented. There is always more you can do after all. - Do we want to mark in the design docs what has already been implemented? - Do we want to remove the implemented parts from the design doc? During the implementation process we might learn something that changes the design. After the implementation the correct spec for a feature should live in the documentation. Would we care at this point to update the design docs? Or do we consider them as transient document where we kick out what has been implemented. Also during the incubation phase we might change the design based on the feedback we are getting. Would we always go back to the design doc to update? I kind of like the idea that the current design docs only contain what we are planning to do. That way they are also very suitable to be used as a roadmap (more on this later). Thoughts? Hans
