I have used slightly differing versions of the below to outline what should be included in an estimate, please consider each business environment, team and delivery process will have differing contexts (i.e know your context – KYC). For an overview of different estimation methods and templates please my Software Development & Delivery Estimation article. Depending on the phase of the initiative / project (pre-discovery, discovery, delivery), delivery methodology and type of work at hand (ie small agile feature, initiative, or large project) will determine which of the below estimate method to apply.
Generally there are two types of estimates:
- High-Level – i.e very early on, not much context, quick sizing based on little information
- Detailed – i.e close to delivery, team involved, more detail, agile point based estimation
Our delivery estimates consider a person day to be 8 hours, however when scheduling work (assuming working outside a flow based agile delivery model here) we should consider a person day of 6-7 hours (not 8) which should cover non-delivery work such as meetings, lunch, learning, training, discovery, estimation, production support, backlog grooming, story breakdown sessions, unplanned leave etc. If working in an agile method, velocity based planning will naturally take care of these items.
What should be included in an estimate
- Analysis effort
- Technical design effort
- Development effort
- Unit testing
- Manual testing of solution
- Test automation (including functional, integration/API, E2E and smoke tests)
- Refactoring tasks (if possible / agreed)
- Story kickoffs, code/peer reviews and walkthroughs
- Build pipelines, environment setup & configuration and deployment infrastructure
- Defect fixing in system testing, end to end testing & user acceptance testing phases
- Deployments through lower environments to production
- Feature toggling / rollout strategy in production and support
- Monitoring & alerting tasks
- Production defect fixing
- Documentation
What should not be included in an estimate
- Buffer, fat or contingency (this will be added at an initiative / project level when putting together estimates to share and in delivery plan). We want to avoid layers of buffer/contingency at task, feature, initiative and program level etc.
- Spikes / prototypes / proof of concepts – these should be estimated / played as a seperate time-boxed task (ideally to inform your estimation)
- Formal UAT Support – scheduled as a seperate task in delivery plan on large projects
- Formal Warranty period / Hyper-care – scheduled as a seperate task in delivery plan on large projects
- Customer meetings
- General development activities outside this feature
- Learning time, training, guilds, conferences etc
No Comments
You can leave the first : )