Two questions we often hear are:

  • How do we handle a project’s workload?
  • How do we estimate how much we can get done in a sprint?

Some agile teams refer to this as planning sprint velocity. Whatever it’s called, the goal is to decide, based on historical data, how much work a team can realistically commit to in a given week.

Teams Who Estimate Better Manage Workloads

Let’s start with the basics. Typically, each engineer has a 40-hour workweek. The natural assumption might be they can therefore handle 40 hours’ worth of tasks, like stories. But if the entire 40 hours are committed to tasks, it forces you to “cannibalize” the quality of the team. Why? Because inside that 40-hour workweek, the team is still going to have stand-ups, grooming and sprint planning meetings, and more.

Since agile projects live and die by their ability to be efficient, all agile teams are committed to allocating their time to deliver the best possible product in the shortest amount of time. One powerful way to do that is with estimation, where teams consistently estimate the amount of work needed for each task.

Project Optimization Through Agile Estimation

At Zibtek, we define an “efficient team” as one that’s at 60 to 70 percent. That translates into about 25 to 30 hours for development. This can understandably cause concern, particularly for clients who haven’t been through the agile development process before. They wonder what it will mean to their project. Won’t the team end up getting much less done?

Surprisingly, the opposite is true. Employing estimation in the software development process generally means more gets done. How so? When you protect quality and have triggers built in for quality, your Devs are actually making the process smoother. There’s less rework and fewer bugs as you move through the project. And that’s important because when you don’t do these quality “pieces,” the bugs and reworks will come back to haunt you—and cause more work.

Estimation Story Points in Agile

In some cases, we’ve seen not using estimation force teams to spend three to four hours fixing a feature that didn’t get enough thought and planning. So, making sure we have that buffer to keep quality high is extremely valuable as we can:

  • Do architectural plannings
  • Think through and hash out different scenarios
  • Shift left
  • Get all QA people involved
  • and more

How to Estimate Story Points

When creating estimates or calculating velocity, software engineers factor in their completed work in story points over time. This helps for short-term planning and gives the team an idea of how much work is too much work.

We believe it’s far better to know with certainty what work will get done when we say it will get done. It’s the best way to avoid scrambling and working overtime to meet deadlines, or worse, missing a deadline altogether. Using estimation allows teams to be more realistic about the work they need to get done and builds trust with our clients. When we can confidently say, “that normally takes about a week, but we’ll give you a better estimate once we begin,” we know we’re giving our client the best and most reliable software development experience possible.To learn more about agile estimation techniques and how they help workload management, contact the team at Zibtek today with any questions you might have.