A Story
On Sprint days we reflect on our accomplishments (or lack thereof) for the previous 2 weeks. It’s about 20 minutes before we jump on zoom and share our thoughts and reflect. I look at our board. I filter for my name, and I see the same tasks I started two weeks ago all "In Progress".
I can easily justify why I wasn’t able to complete the sprint tasks. The justification always included something about requirements changing or some unforeseen roadblock or lack of data or some other "reasonable" excuse. My tasks are simply different than what everyone else is working on, right?
The truth is that my tasks are not that different than anyone else’s. The only difference is my lack of experience. Experienced engineers can more accurately measure how long a given task will take and then complete the tasks accordingly.
Here I will try and describe some rookie mistakes I made and some pointers for creating tasks to complete during sprints.
Give Reasonable Time Estimates
One of the biggest mistakes I make is estimating how long a task will take to complete. Now one of the reasons why my estimates are so inaccurate is because I lack the experience to know how long a task will take to complete. If you’ve never climbed Mt. Everest, it’s hard to know exactly how long it will take to climb.
To address this time estimate issue I try to think more granular and lean on my more experienced teammates to help me estimate tasks. When I say "think more granular", I don’t mean to think of every single line of code and testing needed, but instead, think of the larger steps needed to complete the tasks. A good example might be deploying a new feature. Here, the larger steps include writing, reviewing, testing, and then deploying code. Depending on the nature of the feature, writing the code might take a couple of hours, reviewing and testing might each take a day, and deploying the code might take another day or two. So here we can estimate about 4–5 days to develop this new feature. Longer than you initially may have thought, right?
Sometimes when we define sprint tasks teammates and managers might challenge those estimates. They might say something like "hey, I don’t think it will take X days; it should only take half the time". Now, if you don’t have a solid understanding of what’s involved to accomplish the task, you might be easily persuaded to agree. It’s important to spend some time before the next sprint planning and define essential tasks and estimate how long it will take to accomplish them.
Clear Task Inputs and Outputs
Before creating a new task, it’s important to clearly define what are the inputs and outputs. The input consists of your time, effort, and other materials such as a design document. The output equals something needed such as a new product feature.
The more clearly defined these inputs and outputs, the more clarity your team and management have about what you’ve accomplished or what you are trying to accomplish.
Here is an example of a bad task definition:
Input: 3 days
Output: new feature
So let’s dissect. The input is 3 days of work which equals about 27 hours of dedicated time (assuming 9 hours of work per day). The output is a "new feature". What exactly is that new feature? There are no other prerequisites needed to accomplish this vague goal? Do you have the right permissions to access the codebase? Does the accomplishment of this task mean that the feature is deployed to customers or just that the code works locally?
Okay, let’s improve our example a bit:
Input: 3 days, bob’s design doc
Output: Improve console banner
This is an improvement since we now reference a design document that presumably provides direction. Our output includes some clarity regarding what is begin built, but the defined task is still pretty vague. 3 days is also quite a bit of time. Usually, when there are more than 2 days allocated to a particular task, it is a red flag that the task can be broken down into smaller parts.
Instead of describing more bad examples, I’ll provide an example of a pretty decent task definition:
Input: 1 day
Output: Design Document Detailing Implemention for Console Banner Search Index to Database
Input: .5 Day, Design Document
Output: Review Design Document with Team
Input: .5 days, Jim Henderson (Dev) Support w/ Implementation
Output: Add Index for Console Banner Search
Input: .5 days, Mark Johnson (DevOps) Support w/ Monitoring Results
Output: Locally Test added Index for Console Banner Search
Input: .5 days, Test Results, Tech Lead Support Approving Pull Request
Output: Review Code and Results from Local Test, Commit and Merge to Dev Environment
Input: 1 day, Jenn Smith (DevOps) Support Deployment
Output: Deploy Improved Console Banner Search to Customer
Hopefully, you get the idea. Tasks take much to complete and aren’t fully dependent on your skillset and expertise. It often takes a village to complete a task. Any failure can have major consequences.
Reflect and Iterate
This might sound obvious, but it’s important to reflect on the goals you defined and whether you were able to complete those goals in time or not. At the beginning of this article, I set the scene of reflecting on my recent sprint with my team. That active reflection during those occasions helped me think about how to improve my sprints.
I asked myself "why wasn’t I able to accomplish this task", "was my task definitions too vague", or "did I give myself enough time"?
I encourage everyone to spend the time to ask themselves these hard questions and track progress. Maybe experience creating tasks with underlying subtasks. Maybe allow yourself to adjust estimates after writing the initial code. How about measuring the initial time estimates and the actual time estimates. Perhaps earlier our initial estimates and actual estimates are significantly off but are slowly converging.