In the prior post, Units Of Value, I said that defining the units of value is key to understanding and delivering what your customer needs. In order to create a delivery plan, you need to construct a repeatable process for converting units of value to units of work.
This is difficult when a software development process is not very mature, not because the team doesn’t know how, but because the how is different every time. The conversion of what your customer needs into what you are going to build is a solution design exercise.
If my units of value are stories, features, requirements – then my units of work are software components in some framework. Each platform will have different types of components and sub-components. Each unit of value will get a “punch list” – or list of components that need to be built. Some of the components will be shared across units of value, others will be bespoke to a specific unit of value. If there is environment build out (hardware, infrastructure, etc) this is shared across all or most units of value.
There is no right way to do this conversion. There is only consistency, predictability, and integrity. They way to produce these three is to adopt some principles that make sense, adapt your methodology to fit your principles, and refine both your principles and methodology to get better results each time. For this reason, teams that stay together over a series of projects will consistently perform better in this effort than teams that form for a single project and then disband.
No Comments