How to Scope Tickets Properly
I was given the task to scope out some tickets for next year and to assign time estimates to them.
How should I go about doing this? I have 4 tickets to time-estimate.
At a high-level, I'm thinking that I should be working to decompose the tasks down to simpler parts which should also be simpler to estimate. But how granular should I go into decomposition? Looking at my (more experienced) colleagues' work on estimating their tickets, there estimates for their tickets are anywhere from 1 to 4 weeks.
They also jotted down a few bullets on assumptions and some of the decompositions involved.
So decomposition I would guess is step 1.
Before I even do that though, maybe I should be speaking with the stakeholder assigned to the ticket so I can get a better understanding of what's involved.
So I need to a) talk to stakeholders; b) decompose the ticket into chunks; c) come up with an overall time-estimate.
Did I leave anything out?
The fundamental challenge here is that it's hard to predict the future and know how long something will take before doing it.
Thanks!
Discussion
(2 comments)- 1a month agoTech Lead/Manager at Meta, Pinterest, Kosei
That seems like a lot of work for an estimation...
I'm probably coming at it from too extreme an angle due to my startup bias for the past 2 years, but I'd rather do the work instead of the "pre-work."
The amount of time you spend for an estimate is correlated to how long the project is. If it's a 1 year project, for example, you can justify spending weeks to gather information and anticipating roadblocks. But most mid-level SWEs are not planning out work for a year. (My startup bias is relevant since we're hyper-focused on the short-term.)
If the project is roughly going to take a month, then you should timebox the estimation to be a few days.
For larger projects, after you do a read through of the criteria, it makes sense to me to talk to the key people involved or the person with the most context.
- 1
a month agoTech Lead @ Robinhood, Meta, Course HeroWhen it comes to estimates, the process is overall like this:
- Decompose the task at a high-level - Don't think too much about code at this point, mostly English
- Come up with an estimate for each individual sub-task - Think as close to the code/implementation as you can. If you have 0 clue how a sub-task works (e.g. it's part of a codebase you have 0 experience in), track down a domain expert and talk to them
- Add up everything from #2 to create an overall estimate - This is just math
- Get feedback on what you've done - In particular, you want to check if any of your estimates are off or if sub-tasks need to be broken down further
Ideally an sub-task equals 1 commit, but for a large project, having that level of granularity would be insane/impossible. However, I do think a sub-task should take 5 commits at most.
Seniority is another factor. If you're very senior, it's possible you don't really need all this decomposition and estimation and you can just throw a rough ballpark out there, jumping straight into the work. If you're more junior though, this exercise is incredibly helpful as granularity brings clarity and clarity leads to action.
Here's some other good threads about estimation:
