The myth of estimation
Estimation of software development is never scientific, though software is one of the most scientific miracles that stupid sapiens have achieved. It is so tricky, and you often don't even believe what you estimated.
Your peers, your product managers and your supervisors expect you and your team to estimate everything, and often take your estimation as a "commitment" when you try very hard to explain the the inaccuracy is the nature of estimation because we are Terran not Protoss.
Nevertheless, it is life of engineering leaders and we have to embrace it. Estimation is not just for your sprint plan, but more importantly, it is for the communication with other sapiens. Because Mankind's communication has different levels, Mankind's estimation should do the same.
You should make the range wide enough for flexibility because the item is raw at the moment. The size estimation should be conducted by a leading engineer with the input from the product owner. Details are welcomed, but they are not compulsory. Use assumption when there is ambiguity, and never spend less than 30' for one item. An example of size estimation could be like:
The something too large, like the XL in my table, re-considerate its scope, and divide it into multiple items with lower sizes.
Sizing estimation is cheap, and very rough. So, only use it in your roadmap, or headcount planning. It is not suitable to plan a project's timeline.
There are 3 steps to make a proper high level estimation for you to make a project timeline:
When the 3 steps are finished, you are good to go to use the data to draw the timeline for your PM or boss. There are different ways to do it: simply use the max or average number for each work stream, and I personally recommend using the max; or run a Monte Carlo Simulation (This is fancy, so I may need to write another blog and some code snippet for workable practice.).
Another important thing is: when the project is too large, divide it into a few small sub-projects, and divide the big team to small sub-teams mapped to the sub-projects. Then, run the estimation for each sub-project/sub-team, and don't do it for the whole project.
Finally, you might get your timeline like this:
Looks nice! Seems it is time to roll your sleeve and get your hands dirty with code. But wait, let's make low level estimation for your real coding tasks.
Low level estimation
Your peers, your product managers and your supervisors expect you and your team to estimate everything, and often take your estimation as a "commitment" when you try very hard to explain the the inaccuracy is the nature of estimation because we are Terran not Protoss.
Nevertheless, it is life of engineering leaders and we have to embrace it. Estimation is not just for your sprint plan, but more importantly, it is for the communication with other sapiens. Because Mankind's communication has different levels, Mankind's estimation should do the same.
Sizing
Sizing is the top level of estimation. I also call it 30,000 feet high estimation. The goal is to size the raw items for your quarterly or even yearly roadmap. The item to estimate could be a short description of a project, a new feature, or a solution proposal. In this estimation, we only give a size to the item, and T-shirt sizes are very common for this scenario. Importantly, a size means a range of time, and an organization should always define the mapping between size tags to the ranges. For instance:Size | Size Range (Person Weeks) |
XS | < 1 |
S | 1 - 6 |
M | 6 - 15 |
L | 15 - 30 |
XL | > 30 (not sizable) |
You should make the range wide enough for flexibility because the item is raw at the moment. The size estimation should be conducted by a leading engineer with the input from the product owner. Details are welcomed, but they are not compulsory. Use assumption when there is ambiguity, and never spend less than 30' for one item. An example of size estimation could be like:
Item | Size | Comments |
Project X | L |
Assumptions:
|
The something too large, like the XL in my table, re-considerate its scope, and divide it into multiple items with lower sizes.
Sizing estimation is cheap, and very rough. So, only use it in your roadmap, or headcount planning. It is not suitable to plan a project's timeline.
High level estimation
When it comes to the exiting kickoff moment of a project. Your stakeholders always want you to provide a timeline, and sometimes give you a deadline to finish. If you are a stakeholder, I recommend you should also have timeline. That will make the project the project more predictable. To make timeline, a high level estimation is needed.There are 3 steps to make a proper high level estimation for you to make a project timeline:
Step 1: Finalize the solution
First of all, the technical solution must be ready. Your leading engineer needs to finish a technical design and get it signed off by the team. A complex project probably needs sign-off by multiple parties such as dependency teams, downstream teams and security.
Step 2: Break down the scope
After the solution is settled, break down the scope into multiple work-streams. Those work-streams are the items for estimation. Here you need your leading engineer again, and more finely grained is better.
Step 3: Group estimation
Invite the Dev team for a group estimation session. The leading engineer needs to explain each work-steam to the team. Then, every team member needs to give two numbers for the work-steam:
- minimal person-days: the most optimistic estimation for the work-steam.
- maximal person-days: the most pessimistic estimation for the work-steam.
When the 3 steps are finished, you are good to go to use the data to draw the timeline for your PM or boss. There are different ways to do it: simply use the max or average number for each work stream, and I personally recommend using the max; or run a Monte Carlo Simulation (This is fancy, so I may need to write another blog and some code snippet for workable practice.).
Another important thing is: when the project is too large, divide it into a few small sub-projects, and divide the big team to small sub-teams mapped to the sub-projects. Then, run the estimation for each sub-project/sub-team, and don't do it for the whole project.
Finally, you might get your timeline like this:
Looks nice! Seems it is time to roll your sleeve and get your hands dirty with code. But wait, let's make low level estimation for your real coding tasks.
Low level estimation
Low level estimation is used for story or task estimation. In a nutshell, it is for the real executable job. Normally, low level estimation is being conducted in grooming or sprint plan meetings if you are using Agile estimation method.
Before the estimation, there are two important preconditions:
- Precondition 1: The stories/tasks are created with detailed description and acceptance criteria.
- Precondition 2: There are a list of completed stories as the baseline. Compare a new story with them to make the estimation.
When both preconditions are met, the Dev team conduct an session to estimate each story/task in the backlog as following steps:
Step 1: Groom the story/task
Dev team groom the story/task so that the story/task is executable. Everybody should be on the same page on how the story/task is going to be implemented.
Step 2: Estimate the story/task with points
Everybody gives a point for the story/task by comparing it to the baseline stories. The point is a number in Fibonacci sequence.
Step 3: Debate the estimation difference
The highest and lowest point givers have a debate for their reasoning.
Step 4: Finalize the estimation
Repeat step 2-3 until the team have a consensus, then finalize the final estimation point for the story/task.
The low level estimation results are used for Scrum/Kanban planning, and velocity tracking.
Recap & Summary
To summarize, there are three levels of estimation:- Sizing estimation, T-shirt size the ambiguous projects, and use them for roadmap and resourcing plan.
- High-level estimation, break down the project into work items with a workable solution, and estimate each item as a group. Use them to make a timeline for the project.
- Low-level estimation, a.k.a, Agile estimation. Point the tasks or stories in the backlog, and use them for sprint/kanban planning.
Sega Genesis 1601 1601 Video Game Cartridge for sale | FABB 10cric 10cric 우리카지노 쿠폰 우리카지노 쿠폰 fun88 fun88 366mlb prop bets today - TopBet
ReplyDeleteSbobet: Football Tips and Predictions - T&Cs Apply
ReplyDelete(soccer tip) is a betting service, developed by 더킹카지노 a sbobet ทางเข้า player and a betting company. to be the best in the world or anyone who has fun88 vin ever been involved with betting
Interesting post!
ReplyDeleteI enjoyed reading your article on the myth of estimation in software development. It's refreshing to see a perspective that acknowledges the complexities involved in accurately predicting project timelines. Your insights shed light on the challenges of how to estimate software development time, and I appreciate the emphasis on embracing uncertainty in this process.
ReplyDelete