On work breakdown
Most of the people either follow or have heard about the INVEST for stories and SMART for tasks principles. In this very short article, I will be sharing a few rules I follow when it comes to breaking down a story into tasks.
A key activity of our teams is the breakdown of work into smaller and actionable tasks. We do this at the beginning of the week (or sprint), during refinement, and at any time as soon as need arises. At times, developers ask me about how to keep this activity less expensive, how a sub-task should be like and how granular should it be.
I find some principles in the WBS guideline agreeable (except for the 100% rule because of variability), esp. on keeping the breakdown outcome-oriented rather than action-oriented, e.g. “User creation REST endpoint” vs. “Create database schema” + “Create CRUD methods” (which is also a vertical-slice vs. horizontal-slice example).
Most of your tasks are time-bound and tools like burn-down/up may be employed to keep track of the progress. I often recommend using the 1–2–4 scale for quick time-based estimation: the task can be completed in an hour, less than half a day or in half a day. Half a day is a good check point to tell if more time should be allocated to the task or more eyes and hands needed to move it forward quicker.
As much as we want it to be, some tasks just can’t be SMART, especially when predictability is low (e.g. spikes). But for a rather stable team (with little effort put on R&D and introduction of new technology), SMART is applicable and hopefully my recommendations too.
If you love feedback (you should!), categorize your tasks (because control chart was originally designed for sampling on process output) and monitor the trend of shifting of average and to make corrective action using SPCC. Track down the special causes (stop the line!) as they are the cheapest to detect, and use the data to create a continuous improvement culture within your company.