Tim Hwang
- PM identifies 🔎 user requirements
- UX designs 🎨 them
- Dev implements 🔧 them
(Leaving out ops, QA, etc. for now)
PM and UX write story and pass to dev as JIRA
User stories !== developer action items
- Tickets from PM and UX are feature-based, but not all features are created equal
- Some features are simply too large to be actionable
- It's no secret our estimations can use some work
- Poor story point estimates lead to inaccurate (and missed) timelines
- Ambiguity in implementation details leads to developer frustration and angst
Outcome: Shoddy product
Note:
Other examples
DR-5212 - 10 SP ticket for a huge issue -- helped via subtasks and follow-up tickets PL-6681 - grid child rows didn't yet exist ORION-3959 - status component doesn't exist, missing API data PL-6997 - 3 discrete form states can be implemented separately; missing metrics redux stuff
- Extremely complex feature
- Initial ticket included: link to the mocks, a sample API request, and 3 bullet points
- Story points: 12
This ticket is NOT actionable! Where do I start? I want to cry.
(Where did the number 12 even come from!?)
- Top-down: tech lead does all "actionizing"
- Consensus: "actionizing" during planning meeting
- Bottom-up: developer "actionizes" their own ticket(s)
Proposal: bottom-up approach is the best, so let's try it
Note: Top-down can lead to centralization of knowledge; people at top never grow Consensus is good for incrementally improving estimates, but is nowhere near the final step
Before starting work, dev translates tickets from being feature-based (user-oriented) to being implementation-based (patchset-oriented)
Note:
Example: pulling out action items as subtasks
- Tasks are recursive trees 🌲: each subtask is either its own task tree or a leaf
- Leaves 🍃 are tasks that are sufficiently small to be actionable
- How do we collect all leaves? Tree traversal algorithm
<AudienceBuilder/>: Redux-aware container + <ExpressionBuilder/>
├─ Redux-aware container: ACTIONABLE
└─ <ExpressionBuilder/>: <Container/>, <Left/>, <Right/>
├─ <Container/>: ACTIONABLE
├─ <Left/>: <LeftBlock/>, <LeftContainer/>
│ ├─ <LeftContainer/>: ACTIONABLE
│ └─ <LeftBlock/>: <Header/>, <Breadcrumbs/>, <Grid/>
│ ├─ <Header/>: ACTIONABLE
│ ├─ <Breadcrumb/>: ACTIONABLE
│ └─ <Grid/>: checkboxes, drill-down, etc.
└─ <Right/>: ...etc...
Dependency graph allows you to identify what tasks are parallelizable, and what are high-priority blockers
- 22 story points -- much more confidence in this estimate
- Clarity in implementation details
Outcome: Robust, bug-free product
Estimates that are the sum of many granular tasks will be more accurate than holistic estimates
(Again -- where did the number 12 even come from!?)
Small, concrete features are the easiest to unit test
Incrementally written unit tests = very few regressions
(48 unit tests over 24 tickets -- not that much work)
- Concrete task leads to productive, focused discussion with PM and UX
- Awareness of dependencies makes it easier to pivot when requirements change
- More deficiencies identified up-front
- If one subtask is blocked, easy to identify what can still be worked on
- Limit scope creep: clear acceptance criteria, non-MVP reqs can be moved to follow-up tickets
Atomic tasks = smaller, more focused commits = happy reviewers 😊 = faster merging
Turns out critical thinking helps understanding. Who knew?
Technique: Before starting work, the developer should translate tickets from feature-based (user-oriented) to implementation-based (patchset-oriented)
- Better estimates
- More robust code
- Improved iteration speed
- Faster review turnaround
- Deeper understanding of requirements
(disclaimer: not actually a waterfall)
Short answer: no
Long answer: noooooooooooooooooooooooooooooooooo
- Subtask list was highly mutable and changed constantly
- Up-front planning is NOT against the spirit of agile
- Agile = ability to respond quickly to change
Targeting in Tabbed Manage Blade
Targeting in Campaign Wizard
"A stitch in time..."
- Up-front planning took a day at most
- Identified importance of strict separation of concerns (routing, data access, wrapper, form layers)
- Result: porting from manage blade to campaign wizard took ~30 minutes, likely saving weeks of rewriting
- How many existing features had to be rewritten for the campaign wizard?
Great! Stick with what works
However, I personally think individual sizing is better and is worth trial running at least once
Note:
Again, top-down leads to centralization of knowledge, and consensus isn't precise enough
- Practice makes perfect
- As you get into the habit of breaking down tickets, you'll naturally improve at identifying subtasks
- Process is entirely up to you -- find the workflow that works best for you
- Dev skillset is focused: be very good at this one thing
- PM skillset is discrete: be good at these fifty things
Easier for devs to learn a subdomain of PM than it is for PMs to learn a subdomain of engineering
- You work more efficiently for the company
- You also massively increase how hirable you are and what salary you command (remember: TPMs are expensive!)
Win-win!
- Definitely wasn't ever made clear to me 🤷
- Regardless of how "obvious" it might be, at the end of the day, we're not doing it, and that's what matters
- How does your team currently size tickets?
- Who makes tickets actionable?
- How are bad estimates handled?
Note:
Possible next steps:
- Better CR culture
- Pair programming
- "Rotational" tech leads
- Devs participate in user research
Link to slides
Edit