How to Deflate Ballooning Tasks

Megan Marquardt discusses best practices for keeping your work in scope.

Full Presentation: http://code.bloc.io/how-to-deflate-ballooning-tasks/

Transcript

1. How To Deflate Ballooning Tasks Scoping, Re-scoping, and Postponing
2. What’s The Point? • Be efficient with your time • Be quick in your development • Be communicative with stakeholders
3. Strategies
4. Define and Scope The Problem ▪ Get to the root of the problem: ◦ one time migration fix? ◦ major issues with models and their interaction? ◦ which parts of the app are involved? ▪ Set the scope of what you want to solve.
5. Acknowledge Possible Complications: Don’t Solve Yet ▪ Figure out what could pop up in your development that might become a road block ◦ unfamiliar part of the app? ◦ modal overlay: i’ve run into issues with those before? ◦ frontend: i’m clueless? ◦ are there even tests for this yet? ◦ how reproducible is the issue? ◦ how complex will the solution need to be?
6. Throw A Gut Estimate On It Use your experience, use the complications you considered, and throw some number at it. The initial estimate doesn’t matter as much as how that estimate evolves. If you have no clue, break it down into smaller pieces: • how long do migrations take to write? to optimize? • how long does writing the test take? • how long does review usually take?
7. Who Cares? Not just you! Everyone’s reasonable here, throw them a ballpark estimate so they are in the loop. You’ll probably go over, that’s fine. Use phabricator tickets, phabricator work boards, spec slides, proposal documents But, yes. You care. The estimate is for yourself to compare time spent vs. work done. Keep your own notes to stay on track and within scope
8. Monitor Your Own Work Monitor yourself and how fast you’re working relative to your initial estimate. Hours estimate: check yourself at each increment of the estimate Days estimate: check yourself at each partial increment of the estimate Weeks estimate: you done messed up. get back to the first step, then we’ll talk.
9. Re-Evaluate Scope If you are significantly going over your estimate by large factors, it’s time to re-scope. Break it down into smaller pieces: • Consider the engineers who will be reviewing this code • Consider your own concentration: don’t solve everything at the same time • Split up work vertically by component or horizontally by layer in stack Cut out pieces: • Don’t solve everything at the same time. Scope down, postpone peripheral fixes.
10. Rinse and Repeat Run around in thoughtful circles until there’s shippable chunks of code scope + re-scope monitor your work who cares?
11. Inform The Team Hopefully you avoided majorly ballooning tasks, and you’re ready to throw up some code diffs. You know it, you tell the story: ▪ Set the boundaries of what to review ▪ Briefly explain the path of task ballooning ▪ Acknowledge what wasn’t addressed
12. Case Study
13. And So Enters: The Problem Mike Dekker has too many notifications.
14. Define and Scope The Problem ▪ Noisy notifications are useless ▪ Need to batch archive stale notifications in the database ▪ Need to fix the day-to-day archival of assignment and message notifications when the sources are modified
15. Acknowledge Possible Complications: Don’t Solve Yet ▪ Notifications relate to multiple models ▪ Some of notification archival may be partially implemented ▪ Expect missing or scattered unit tests
16. Throw A Gut Estimate On It My gut, i.e. my experience, tells me writing a migration to archive notifications and fix how they’re archived in app will take a day. ▪ Migrations for updating a large set of data related to several other models generally takes me half a day to find a query that is optimal and runs in a reasonable amount of time. ▪ Writing a test for notification archival and fixing the notification should take about half a day. ▪ Code diffs have been averaging an hour or two turnaround.
17. Who Cares? • This was a self-discovered bug: loop in #mentor-dashboard • We discuss, we decide: 1. assignment notifications should be archived when checkpoint is completed 2. message notifications should be archived when message is responded to
18. Monitor Your Own Work Half a day in: ▪ half the migration written, behind schedule but not significantly ▪ assignment notifications still not down to a reasonable count for mike ↳ what did we miss? those students are from last year, maybe we could also archive the assignment notifications for students that have completed their course? A few more hours: ▪ Half focused on other cases of when notifications should be archived ▪ Half focused on solving the checkpoint completion notification archival problem
19. Re-Evaluate Scope It’s been a day, and if progress continues as is, I’m at 4x my gut estimate: ▪ Revisit the initial scoping steps, dividing future work into distinct pieces Enrollment Changes Source: Message Source: Assignment Source: Nudge Source: FunctionalAssessment M M T E S T T E S T T E S T T E S T freeze with mentor freeze without mentor, unfreeze transfer mentor dropout course completion M M T E S T T E S T T E S T T E S T T E S T
20. Who Cares? Brought this up to the #mentor-dashboard chat, documented the new scope and proposal and opened up to #mentorship
21. Monitor Your Own Work Middle of second day: ▪ Progress is steady, I’m on pace End of second day: ▪ All implemented except for transferring notifications between mentors (which has a plan, NDB) and archiving notifications for graduating students.
22. Re-Evaluate Scope I ran into a potentially ballooning part of the task: ▪ I investigated the end-of-course processes for a student ↳ looks like there’s 2 rake tasks that run on the last day of a course: email and graduation standing fix ↳ those should be consolidated into one graduation task ↳ oh man, graduation could balloon into so many tasks, how would be deal with that..? ▪ Postpone the end-of-course problem, this is now out of scope ▪ Don’t ignore it: throw thoughts and notes into a new phab ticket
23. Inform The Team You tell me…
24. Q&A