When 7pace decided to build a time tracking solution for the GitHub universe, our developers thought it should be a somewhat straightforward project. Take the Timetracker we already built for Azure DevOps, and make it work for Github users. No sweat, right?
If you’re a developer, you probably already see where this is going.
Of course it wasn’t that simple.
“The team [working on the GitHub extension] came from that original team,” said 7pace product manager Sascha Zierfuss. “So although we know exactly what we’re doing, we understand how customers are using it and all that — the new product is in a different realm. So a lot of the assumptions and the knowledge that we had no longer applies.”
In other words, features that were simple to build for the Azure DevOps Timetracker were a lot more complicated to build for the GitHub Timetracker. And that meant, as the team was making time and effort estimates for different parts of the work, they were off — sometimes way off.
“Now we take a bit more time to dive a bit more deeply and think about it a bit more before coming up with an answer as to how complex or how easy or difficult something is,” Zierfuss explained. “We take a bit more time upfront. But that has made our sprints a lot more successful and helped with the planning as well. If there’s something we think we can achieve in, say, a few months, we’re now better able to assess whether we need some help to reach that goal, if we have to cut a few things, and so on.”
As the developers who are nodding along already know, the 7pace team didn’t have a unique problem. Most, if not all, software teams struggle at some point with scoping work, especially when they’re working on something they’ve never done before. But how can your team accurately scope work when every project is something new?
We don’t have a perfect answer — whoever figures out how to solve this challenge will be a hero to the developer community. But we think some of the lessons our team learned about this can help other developers. We think there’s a secret weapon for scoping that many teams haven’t even considered.
Step 1: Keep Calm and Code On
The first thing to keep in mind is that this isn’t a world-ending problem. Yes, we should all be striving to get better at scoping work. But it’s a challenge that literally every software team faces. Don’t believe us? Well, one recent study found that two out of every three enterprise software projects have cost and effort overruns.
66% of enterprise software products have cost and effort overruns
When it comes to scoping work, a little perspective can often be helpful. Keep in mind that estimates are a part of every step of the development process. We’re not giving you permission to give up on trying to be better at scoping, but we are saying: Don’t panic. Keep the work moving forward, even if it turns out your scoping is all wrong. And in the meantime, use these tips to get better at scoping your work.
Project Scoping Best Practices
When trying to scope a project, there are some best practices that can help all teams.
Remember that Building Software Is an Evolving Process
They call building software a “process of discovery” for a reason. As you move through any given project, you can expect it to evolve and change. Requirements aren’t set in stone at the outset of a project, and as you progress through building the software, you may well find that you need to change the requirements along the way to better fit the spirit of what you’re trying to build.
This means that an important best practice is to stay in constant communication — with your team and with your client or organization. Keep every up-to-date on when and how project requirements are changing. This may mean making adjustments to your estimated scope as you go. But over time, your team should get better at making more accurate estimates.
Mind Parkinson’s Law
Parkinson’s Law says that work will expand to fill the time allotted for it. That means that by giving yourself and your team deadlines based on your project scope, it’s just as important not to overestimate time and effort as it is not to underestimate them.
We get it. It’s easy to avoid missing deadlines by giving your team padded deadlines to allow for those unforeseen delays that every software team encounters. But this can just as easily result in taking much longer to deliver on a project than you actually need to, and thus getting in the habit of overestimating your scope.
Combat this by keeping sprints short. This means you get constant feedback on progress and new directions for the next sprint, which will help improve the quality of your time and effort estimates.
Don’t Try to Transfer Estimates
When scoping work, a very important thing to keep in mind is that time and effort estimates are not transferable between different members of your team. Developers vary wildly in their experience, expertise, work styles, and so many other factors that can affect how long it takes them to do a job.
You’ll make better estimates about scope if you do so with everyone’s personal experience and skill level in mind — and even better if every dev on the team is invited to help scope their own work.
Beware of Context Switching
Part of the work that developers do is juggling multiple projects, clients, and responsibilities. It’s not often that a developer or a team will be solely dedicated to one project at all times.
While this keeps the job fun and interesting, it comes with a major downside: Frequent switching between tasks and projects can severely interrupt your team’s flow, which can slow down the work and lead to inaccurate scoping.
This is another area where doing short sprints can help. That way, your team has predetermined blocks of time for different tasks and projects, and can mentally prepare as needed.
How to Scope a Project, Step by Step
Most of these best practices require having some grasp of the time and effort it will take your team to complete a project. But what if you truly don’t know, because the project is something totally new to your team?
Use this framework for collecting information and turning it into a project scope that’s as accurate as possible, even when you’re navigating new territory.
Step 1: Collect All Crucial Information
Before even beginning to estimate a project’s scope, you need to collect every piece of information about the project that might be relevant to the scope. This includes:
- Project deliverables
- All available resources, including team members, money, and work capacity
- Inclusions and exclusions
- Project constraints
Gather as much detail about each of these as you can, as well as any other project information that might be relevant to the scope.
Step 2: Build a Project Schedule
Using all the relevant project information, you can start to sketch a rough schedule for completing the project. In your schedule, start with major tasks and milestones, and once those are laid out, try to break them down further into minor tasks and milestones. For especially long or complex projects, it might help to break up the work into phases, first.
Step 3: Tailor the Scope to Fit Your Team
Every team has different work styles and methodologies. Now’s the time to take your rough project schedule, and adapt it as needed to fit how your team works. This may mean breaking the first phase or milestone into your first sprints. It may mean assigning certain milestones to certain stakeholders to oversee. This will be different for every team.
Step 4: Compile Your Scope and Review
Now that you’ve gathered so much project information and turned it into a project scope, it’s time to review it — with other stakeholders, if necessary — and make any adjustments as needed. This is also the time to put the scope in writing and make sure it’s agreed upon by all the major stakeholders in the project. That way, you can refer back to your scope agreement throughout the duration of the work, and treat it as a guide for making changes or decisions. This can also help avoid scope creep, or any changes that will require time or money you don’t have.
The scope agreement may not be perfect, but having it in place can help negotiations go smoother if your estimates do turn out to be wrong, and you need to make scope adjustments as the project moves forward.
For More Accurate Scoping, You Need Historical Data
One great way for teams to find a starting point for scoping work (even on projects they’ve never tackled before) is by looking at historical data.
We know that time tracking isn’t the most popular thing among software teams (because so many managers use it as a way to micromanage their developers’ time). But we think time tracking can be so much more than that. We think it can be a powerful, if often overlooked, tool that software teams can use to make themselves better.
7pace Timetracker is built by developers, for developers. It’s meant to be a timetracker that runs fully in the background so you don’t even notice it’s there. But all the while, it’s collecting data about the time you and your team spend working, and compiling that data so you can use it to identify your pace, hurdles, and successes — as an individual dev or as a team. The best part? You can use that data to help scope work — even when it’s work you’ve never done before.
We’re not saying this is a silver bullet. Accurately estimating work scopes, particularly on new types of projects, will probably always be a challenge for developers. But by using the right tools, teams can continue to improve their scoping skills.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps and GitHub.
Top comments (0)