Estimation and Velocity of Engineering Delivery - Simfoni Engineering Blog
Estimation and Velocity are serious unsolved industry problems. It applies to us very much but we are not alone. There are 3 distinct factors that determine how quickly you can deliver a feature and how accurately you can estimate the delivery.
1. The completeness of the product backlog corresponding to the feature to be delivered.
- Unless it’s a tiny feature or enhancement, break the feature into Phases. Single Phase deliveries invariably cause delay and come with lots of bugs.
- The backlog item of the Phase to be delivered in this sprint needs to be complete via pre-sprint rituals (formal or informal) before the sprint commences.
- This should include proper screen designs, workflow, and the lot. Think about error reporting as well to the extent the PM can.
- Minimize number of iterations. Once the sprint starts for a phase, iterations must be as close to zero as possible.
2. The Skill of the Programmer.
- Can the programmer identify the pattern against which the design/code is to be done?
- Do they have the knowledge to use the tools/languages/framework to get the work done or do they have to learn it?
- Do they test their own code and are able to regress it after every fix by automation?
3. Experience leads to better estimation.
- Regardless of skill, estimation needs experience to understand one’s own velocity.
- Typically, programmers, if they pay attention to what they are doing, will become estimators by the time they hit 5 to 7 years of experience.
- Leads should know how to factor in programmer estimation as it is an important skill to become a lead.
The key to delivering a product always begins with product management and the clarity with which backlog items are delivered and how various obstacles are pre-removed before a developer starts to work on it. If, for example, you have to integrate with other systems via an API, the PM should ideally pre-test the API and declare it available or talk to the third party they are integrating with about readiness. Lots of cycles get spent when things needed for development (specs, API etc) are not ready for the developer to go full swing. Phasing of features is equally important to measure progress; don’t try to get the whole nine yards done in one shot. Push to production after each Phase, don’t keep things in dev and wait for everything to complete. It’s also useful to roll out the phases in limited Betas (or select customers), so when we are complete, we have a robust feature.
VP of Engineering at Simfoni