Essentially there are 5 levels of Planning for a complex program, having multiple products synchronously developed by multiple vendors in a distributed environment.
- Product Vision
- Product Road-map
- Release Plan
- Iteration Plan
- Daily Commitment
Each one of the above planning level, involves estimation of different artifacts or different levels of requirements by scrum team who are involved in performing the activity / development. Ex. Estimation of EPIC for the release, estimation of the story for the iteration , task estimation for daily commitment, e.t.c.
One is bid estimates or the proposal estimates and the second one is the technical estimates. No pointers to the BID estimations in here in this page. Every sales person has his own estimation techniques or the approaches that he applies in consultation with technical architect. This also involves most of time using industry benchmarks to justify the bid estimates.
However when it comes to technical estimation, experience of scrum team plays a vital role in providing commitments. Industry benchmarks are good start for the first timers but this becomes obsolete over period of time once scrum team gains sufficient understanding of the team-skill and team-experiences which are used as input for the estimates.
Knowing or understanding the past data is good, but more important is current experience of the scrum team member in estimation of that one little unit he can deliver. This of course involves “what I can delivery in the release, or in the product or today, e.t.c.”. Estimating the fulfilment of business demands / expectations. Typical agile requirement structure is given below.
Agile Requirements hierarchy
EPICs spans across the product lines and the stories are specific to a product. Stories could be rolled up to capability and capability to the EPICs (http://www.scaledagileframework.com/features-and-capabilities/). Also EPICs span across the releases and stories are specific to the sprint. Slicing of the user stories is crucial to the success of the sprints. Stories are broken down to implementation tasks.
“Complexity” and the “Effort” are most common outcomes of the estimation activity.
There are different schools of thought on converting complexity to effort. There is surely no formula to convert complexity to effort though effort is directly proportional to complexity. Few estimate the complexity and then convert it to the effort. Few estimate the effort directly. There is a discussion point on which one of these are correct, but there are success stories in either cases, however. As a thumb rule, for high level requirements complexity is estimated and effort is estimated at low level tasks. Complexity flow is top-down and effort flow is bottom up for reconciliation of task level effort to Idea or Feature.
Theme, Idea, Feature or EPIC Estimation
Estimation of the EPICs is most suitable in the form T-shit sizes – S, M, L, and XL. What constitutes the t-shirt size is different for different products or service lines. Though a continuous attempt is done to normalize and standardize the size definitions. Complexity is the core in t-shirt sizing than the effort.
This is what something we used – Complexity and number of user stories:
- S: 1 -2 Simple User Story (Complexity of 3 story points was considered as simple)
- M: 3 – 8 Simple User Stories
- L: 8-15 Simple User Stories
- XL- > 15 Simple Stories
EPIC level estimates are approximate estimates. They are also called as ‘rough order of magnitude (ROM)’ sometimes. ROM comes with -50% to 200% variability. However the t-shirt sizing gives a good view of the size of portfolio / program backlog. While choosing stories for the backlog grooming, ensure the dependencies are minimized as much as possible by splitting the EPICs further, if needed.
EPIC with ‘S’ and ‘M’ sizing are candidates for the discussion in backlog grooming. EPIC as a whole is picked up for grooming (not the partial EPICs or few stories in the EPIC). EPICs with L and XL were kept aside for discussion among the PO community requiring to be broken down further as smaller EPICs OR the capabilities. Such L and XL EPICS should not be candidates for the development even if discussed in backlog grooming and detailed w.r.t personas, NFRs, components, architectural details, etc.
It is HIGH risk and necessary caution to be exercised choosing the EPICs which requires splitting it further. Sizing of the EPICs are performed by the Enterprise Architect and Enterprise PO together or anyone in similar capability having the big picture view of the enterprise.
User Story Estimates
Priority of the story is marked by the Product Owner. This can also be given as an impact on the business or expected monetary value which serves as a priority. This is performed by the Product owner in consultation with Enterprise Product owner and enterprise Architect.
Task Estimation :
One of the deliveries of the backlog grooming is also the implementation tasks for each of the story. Effort estimate for the tasks is given by the development team during sprint planing and also in daily commitment.
- 3 Point Estimation : Estimate based on previous experience, come out with 3 outputs: best case scenario, worst case scenario and probably scenario. These are combined to give a probability for completion.
- Ideal Estimation : Estimate based on ideal day with no interruptions
- Experienced Estimation : Estimation of the task what you think an experienced developer would take to complete the task. Then you try to do comparative estimate for others in the team based on certain obvious assumptions.
- Another format for task estimate is : Task Estimate = 0.6T + 0.3E + 0.05(P+R). This is from a case study on how estimates are being followed ( source : unknown ).
Experience coupled with clarity on impediments helps the scrum team member estimate quickly work remaining and provide commitment.
Bottom up/ Roll up of estimates
Once we have the estimation of the implementation tasks, this is rolled up to stories or the features and helps in refining (if required) the release commitments. Fe agile teams also estimate High level effort for each of the story in addition to complexity.
Finally what documents related to estimation are required?
Quality folks may not like this. Its absolutely no documents other than what is mentioned in this article.
For large organisations where estimation is also done at bidding, certain organisation standards are used to comply policies related to anti-corruption, bribery, transparency, competition etc before the project is own and onboarded. This is limited to this extent. This may or may not have am influence on project level estimation. You can refer to my article on contracts for further information to understand these points,
Summary : For each of planning phase a is combination estimations followed and commitments are provided accordingly.
- Estimate small amounts of work, preferably
- Revisit the estimates quiet often. Involves learning and corrections continuously
- While you estimate , ensure periodic measurable outcome, preferably daily measurable outcome
- Scrum team member who does the work should estimate
- Overall bring agility, experimentation in the way estimates are performed
- Agile Estimation and Planning Book
Image Sources: hyperlinks are provided in respective images