Delivering software on time, every time: Tips to improve predictability
As technology leaders, we’re always looking for ways to improve the pace with which we ship the software. Market conditions change, our customers demand faster turnarounds, and the software world is in constant flux. These factors can make it challenging to deliver fast, with the highest quality, and on a planned schedule.
But risks are manageable when you take strides to make your iterations more predictable. The following essential tips will help make your sprints more accurate, help deliver projects on schedule, and leave customers thrilled they got that new feature even sooner than planned.
Over a period of 3 months, there were several super simple tactical steps we made to get from this:
To this:
If those burn-down charts resonate with what you see or have seen — let’s dive in: it’s always cool to have a few tricks up the sleeve to help keep things on track.
We needed a single sprint goal.
We always had sprint goals, but they never seemed to amount to much more than “finish all tasks on the board.” Well, maybe that’s not exactly what they said, but it was certainly the gist of it. We realized we needed something more defined — a goal we could actually see and touch. For example: “Release new share page to users outside Typeform.” Something that’d be super specific and easy to recognize when achieved.
In addition, we decided to limit each sprint to a single goal in order to maintain our focus and make it easier for us to remember what we needed to do. This also helped us avoid becoming bogged down in details and side tasks, which can quickly derail a sprint. By having a single, clear goal, we were able to focus our efforts better and stay on track. And that’s what we all want.
We wanted sprint goals that are defined by the team
By the development team first and not by Engineering Manager or Product Manager. I’m a big fan of the idea that the people who are actually doing the work should be the ones defining what needs to be done. It just makes sense. Inputs from EM and PM serve as guidance, but in the end, the decision is made by the dev team.
This way, the team can consider all the factors that go into a project and make an informed decision about what’s achievable in a sprint. And, since they’re the ones doing the work, they’re more likely to be accurate in their assessment. In my opinion, this consistent exercise is what had the most impact and led to the biggest improvements.
No changes to the sprint scope
Easier said than done — there are always so many important things, but never enough time. This rule was one of the hardest for us to stick to. But, it was also one of the most important.
Making changes to the sprint mid-way through can quickly lead to scope creep and throw off your entire schedule. It’s tempting to add just one more task or tweak an existing one, but resist the urge! Once you start down that path, it’s hard to stop.
So, what do you do if something comes up that absolutely needs to be addressed? Well, you have a few options:
- You can push it to the next sprint. This is often the best option, as it allows you to stay focused on the task at hand and avoid scope creep.
- You can create a new task for it and add it to the current sprint. This is generally not recommended, as it can quickly lead to scope creep. However, if the task is small and can be completed without affecting the rest of the sprint, it may be worth considering.
- You can try to work on it in parallel with the sprint. This is not ideal, as it can be distracting and may impact the quality of your work. However, if the task is truly urgent, it may be worth considering. As an exception — we do that with our CS Incidents to match the SLA we promise to the customer.
The bottom line is that you should resist the temptation to change the sprint scope. It’s hard, but it’s worth it. No matter how exciting that new shiny improvement is, it doesn’t add more hours into the workday. Just remember that, and your future self will thank you.
Beginner’s hack: commit to what is likely to be done during the 1st half of the sprint
This one is a pretty nice hack to start with if your sprint burn-downs look as scary as ours before all the changes. I’m not saying you should commit to 50% of the sprint scope and then stop working, no. What I am saying is that you should start by estimating what can be realistically done during the first half of the sprint and committing to that.
But isn’t this cheating, you might ask?
Yes, it is indeed.
But only if you keep doing that in the long term. The idea is that, as you get more experience with the new way of working, you will be able to better predict what can be done in a sprint and commit to that. But for now, start small. It’s much better to under-promise and over-deliver than the other way around.
Over time, we began to commit based on the result we wanted to achieve. However, when we first started out, this method helped us realize that planning can be successful and fun. Importantly, it instilled a sense of optimism in us — which was essential for our journey.
Create smaller tasks
Tasks with more than 8 story points often get broken down into smaller subtasks. This allows us to better estimate the effort required and track our progress. This, in turn, helps us to commit to a realistic sprint scope, and, of course, it helps us do work in parallel more often.
Furthermore, predictability increased because finishing just half of an eight-pointer by the end of the sprint results in minus eight points in total. However, not completing one of the smaller tasks that make up the eight-pointer would result in only minus 3 or minus 5 points.
Let that sink in.
Always know how you burn through the sprint
This one is for everyone, but for those owning the delivery especially. A team that doesn’t understand how they’re spending their time is a team that isn’t in control, and a team that isn’t in control is a team that’s going to have a hard time committing to anything.
Sprint burndown is an essential part of the process, and it’s usually a good practice to check it at least once a week. And also to share the results with the team to keep everyone on track. That sounds super easy, and it actually is very easy. And always helpful. Also super easy to forget and not to do.
But what if you’re not the project delivery owner?
You can still help by creating transparency around your work. Share how you spend your time with your team. This will not only help them understand where the bottlenecks are, but it will also help you reflect on how you’re spending your time and whether you could be more effective.
Somebody once even proposed “no-meeting Wednesdays” day as a way to celebrate being on track with our week’s projections by the middle of the sprint (Tuesday). This obviously worked great because who doesn’t love an occasional no-meeting day?
But, in all seriousness, this helped us focus on our work and be more productive. It also gave us an excellent reason to check in with our burndowns daily.
In the end, if I had to pick only one piece of advice, it would be this:
Prioritize predictability over speed.
Speed is constantly changing — and it’s okay. Vacations, sick leaves, research sprints, CS Incidents, you name it. However, predictability — it either exists, or it doesn’t. When it exists — you can ask for more, commit to more, and deliver more. When it does not — you can only hope for the best.
So, focus on predictability instead of speed: because predictability translates to impact. And the impact is what we’re all here for. Right?
Right.
My name is Max Prilutskiy, and I am an engineer at heart who specializes in building products and leading teams. My passion lies in going from zero to one with technology, enabling users to do impactful, exciting, and fun things with software.
If you’d like to work together — let’s chat.
And, if you liked the content — follow me on Medium, Twitter, and LinkedIn.
