Estimated size needs to include all work done by any silo'd team to get the next iteration on the vertical slice to a done-done state in a agreed upon production or production like environment. That means that this includes qa, dba and sysadmin effort to get this out the door not just what a silo'd dev team does. That way the estimate accounts for the time it takes to wade through the red tape of db change requests, glitches in continuous integration, system config changes, qa effort including customer feedback and anything else that creeps up on the scope of delivering your Minimum Viable Product.
Estimating across silos has several additional beneficial outcomes. 1. Metrics gathered from estimates can be used to retrospect the entire process and effort through delivery. 2. It's a start toward deeper collaboration and breaking down knowledge silos - anyone can call bs on an estimate as they learn more about what it takes to execute a change in a part of the system they are unfamiliar with.
This is a break form the conventional hand-off approach. Here teams are unified and have investment in a commitment to deliver value. Your silos are not customers of each other, i.e. - delivering a database implementation to the internal organization, they are collaborators on a value stream.
Estimating across silos has several additional beneficial outcomes. 1. Metrics gathered from estimates can be used to retrospect the entire process and effort through delivery. 2. It's a start toward deeper collaboration and breaking down knowledge silos - anyone can call bs on an estimate as they learn more about what it takes to execute a change in a part of the system they are unfamiliar with.
This is a break form the conventional hand-off approach. Here teams are unified and have investment in a commitment to deliver value. Your silos are not customers of each other, i.e. - delivering a database implementation to the internal organization, they are collaborators on a value stream.
Comments
Post a Comment