Estimate your sprint tasks realistically.

4 years ago, I was building a healthcare product for doctors to monitor and record the body vitals of patients in US hospitals. The application was a webpage that was getting loaded inside a Windows app as a web view. The page contained input controls that rendered differently for different vitals.

The task of developing a new control to chart a vital looked as if it was just an HTML input tag that took a value given by doctors and it would just store the data in the company's database. It was basically a CRUD operation that had a bunch of values.

Here is the mysterious part...

The product seemed simple and the tasks were simple, but my team always had the issue of spilling the sprint tasks into the next sprint and then to the next sprint after that. This was including my tasks as well. Sometimes I finished early but sometimes my tasks would spill to the next sprint.

My old manager was completely 100% non-technical and wouldn't even try to understand the reasons developers used to give for the delay (Yeah I had a story with him which I can't reveal here 😅). I found it extremely difficult to explain or convince him and also his manager about why this was happening in the team. After many sprint cycles, I came to a few conclusions and facts that can mitigate such delays. Implementing these would require discipline and practice.

Let me break it down for you. When you provide an estimate for your task / story in your sprint planning, I want you to consider the below aspects and come up with an accurate, reasonable, and a practical estimate.

1. First, estimate the coding time you would take for the task.

2. Add time taken to complete unit tests, functional tests etc .,

3. Add time taken to address review comments and deployment.

4. Add a buffer for planning, discussions & requirement clarifications.

5. Add a buffer for unexpected roadblocks & dependencies.

6. If the estimate is more than 5 days, consider breaking down the task.

7. Ask other members of the team if they feel the estimate looks realistic.

8. Don't be overly optimistic. Software engineering has a lot of dependencies and unknowns. Stay humble and be open to ad-hoc items.

Once you arrive with a number (say 4 days), add 0.5 days as a buffer for last-minute bug fixes and deployment hurdles. You never know what can happen at the last minute. Your dog can eat your code or your house can get a lightning strike or your laptop can get the blue screen of death which will end up in the IT helpdesk.

"Commit less, deliver more.

Prioritise quality over speed."

Hope it helps,

Manoj