Feb 11, 2019 by Matt Dixon
With companies estimating that 85% of projects go over budget, it's hard to imagine how we'll ever figure out how to do things as planned. Since budget and timeline are so intimately tangled, any team that tries to build software can always find a way to improve their estimates. Finishing projects on time gets you more clients and ensures that people feel they can trust in what you offer.
Here are four ways to ensure you estimate your timeline more accurately for your next project.
If you're going to take an agile route, you need to get everyone on the team to contribute to the conversation. You have developers, testers, designers, and management trying to learn about what's going on with your project. Rather than having to deal with weekly emails from 50 different people, sit them down together for a project talk through.
Everyone is going to have a different perspective when it comes to delivering each user story. If someone in management wants to make it easier for users to jump from your app to a social media app, your testers or developers can shed some light. If they've run into issues, they'll share a perspective to illuminate the features other people are clamoring for blindly.
If there are any major design changes that your design team thinks they want, they should go through other members. If your QA team is overseeing what changes you're looking at for a design, it helps to improve the estimates you make. When everyone feels included, people are much more committed to a project and ready to buckle down for the long road ahead.
At every company, people who don't communicate with other teams are quick to write off their work or their perspectives. That's a dangerous thing for morale or for productivity, as they go hand in hand. Keep everyone in the loop so there's a reason for every decision other people don't understand.
When you're estimating from an agile perspective, you might think that you need to still think in terms of time and hours. But as different teams have different levels of commitment, there's no strict way to estimate "a week." When one team is on vacation and another team is committed to another project during that week, this week isn't going to look like the last.
Try using the concept of story points instead of time, given that your timeline isn't going to account for non-project work. The creep of C-level requests and management concerns comes into every team that starts their week devoted to this or that project. When this happens, there's no good way to estimate how long something takes.
When you have dates, people invest in that concept. They get excited to think that this thing is going to be done on February 1st. When that date rolls around and you're not ready, morale tanks.
Given that every team is estimating their work on different scales, your velocity can be measured in points that make sense to each team.
Come up with a point value for every story so that points can be quickly and efficiently assigned. This allows for quicker estimation and more efficient delivery.
Points should be centered around how hard it is to complete a task. This helps people focus on value instead of time commitment so that no one is spending too much time on something to feel more productive.
When people start estimating how long a task is going to take, they suddenly become superheroes. Most of the members of your team are going to be too self-conscious to tell management how long something actually takes. A task that should take two weeks by any reasonable estimate is going to be set at two days by your most ambitious team members.
When you start out, set a limit of 16 hours of work for any user story. This means that if something takes more than two days to do right, it should be broken into multiple stories. There's no good way to ensure that your team self-polices, so you need to step in as the leader.
Estimating individual items that take half a week and you want to feel confident about don't go hand in hand. When you have your morning scrum meeting, you don't want someone talking about the same task twice without any productivity.
If you've got things in the backlog, you need to have a rough estimate for how long it'll be in the backlog. When it comes time to start working on that item, your requirements will likely change and by then your application is going to have changed its focus.
These are good things, so don't be disheartened by that. The lack of accuracy of previous estimates means that you've done a lot of work to change the way this next product is going to deploy.
Ballpark figures are okay for the backlog. There's no real reason to belabor your decisions in this regard.
When you want to avoid mistakes from your past, you need to have a realistic perspective. This starts with your company's culture, so allowing for people to be wrong, admit they're wrong, and to celebrate others. It's hard to get this going but it starts at the top and trickles its way down.
Agile tools track your story points from the top and allow you to see how long a project took last time. If you want to ensure that your next iteration of any project is on time, take a look at what happened last time. Pull the last few user stories and you'll be able to start the conversation.
When you build software from the perspective of as many stakeholders as possible, you should be focusing on what it takes to improve your team's morale. A happy team is one who delivers on time because they feel good about their own work and the people around them. It's a win-win when you organize your scrums to build morale and increase efficiency.
If you want to strengthen your team's overall structure, check out our guide for more information.
Reach out to our team of experts to start the conversation for your next project.
Contact us