How to Deliver Features on Time: A Guide to Predictable Planning and Development
Everyone knows one of the biggest issues in the software development - you do not meet deadlines and deliver features much later than promised.
You are always late even you team keeps overworking and overburning.
This keeps everyone demotivated and depress.
However, there is a solution that I’ve elaborated when I worked as product owner at Reply.io. It is not a magic button that you can press and suddenly start delivering fantastic results. It’s a repetitive work based on the six step plan that I am going to describe in details in this article. Following this plan will help you get better results from the start, and gradually improve them with each consecutive iteration.
Let’s start.
INVEST in User Stories First
Every feature begins with a user story or a set of user stories. And user story is basically a story about the feature. It describes what the feature is about and how it works. It can be good and it can be bad. There is a way to write good user stories - INVEST:
Independent. The story is self-contained and does not rely on other user stories to be implemented first. Such stories are great for overall development flexibility and planning.
Negotiable. The story can be negotiated within the team and updated as necessary. It is not edged on stone plates.
Valuable. The story brings real value to the end user. Your team focuses on the things that really matter.
Estimable. You (and the development team) are able to estimate the size of the story. This helps with planning iterations and setting realistic expectations.
Small. In a perfect world the user story fits into a single sprint.
Testable. The story has clear acceptance criteria that can be used to verify whether the functionality has been implemented correctly. This ensures quality and reduces the risk of rework.
In addition to these criteria, a good user story typically follows this format:
As a [user role], I want to [action] so that I can [benefit].
For example:
As a customer, I want to view my order history so that I can track my purchases.
Make Demos of The Features That You Are Going to Develop
A demo is a simple but powerful technique.
It not only effectively explains to every stakeholder what the feature is about, but also greatly helps further collaboration over the feature. During the demo, the most obvious mistakes or pitfalls may be revealed, which is much better than if they are found later during the development stage. It might happen that you will need to get back to the INVEST stage after the demo to rework the feature.
A good practice is to make a demo with some visuals or even an interactive prototype showing how the feature works.
Break Down User Stories Into Smaller Tasks
Now, when you have an already demoed feature consisting of a bunch of user stories, it is time to break them down into smaller chunks.
Smaller tasks are more manageable pieces of work. The smaller the task, the easier it is to estimate, and the more precise the estimation will be.
Smaller tasks are easier to track progress. They are much better for overall morale and don't give the feeling of an endless piece of work.
Completing smaller tasks in shorter cycles enables faster feedback and iteration. This reduces the risk of investing significant effort in the wrong direction and allows for course correction early on.
Facilitate Q&A Sessions with Developers
Even after the demo, and assuming that everyone has read your user stories, be sure there will be enough questions from the developers. To gather and answer their questions you can use different techniques:
If the team is open enough, organize a Q&A session and answer all the questions at the same time. Make sure the developers have read the feature documentation and come prepared to the session.
If the team prefers a more written style, give them a set timeframe to read the feature documentation and make comments. They can hold a discussion right in the document.
Whatever method you choose, make sure that the feature is understood by everybody, and there are no blind spots before moving to the next steps.
Estimate Tasks Properly During Planning Sessions
It does not matter how you prefer to estimate tasks—using story points, hours, or other means of measurement.
Make this an ongoing, regular process for the team.
Teach the developers to estimate properly.
There is a tool called an estimation matrix that can help you with a better estimation of the tasks. This is a visual aid that helps teams estimate the effort required for new tasks by comparing them to previously estimated tasks of similar complexity and scope. Each cell in the grid corresponds to a specific story point value, and teams can use this to quickly estimate new tasks based on their perceived complexity and effort relative to the existing tasks in the reference sheet.
Having passed several estimation cycles, the development team will make more and more precise estimations each time.
Measure Team Velocity and Balance Team Load
When you know how many story points/hours your team has committed to the current iteration, you can start tracking how many story points/hours your team has actually delivered. This allows you to calculate your team's velocity.
Knowing your team's velocity makes the next planning sessions more predictable in order to remove overcommitment.
Let’s say, for the last three iterations, team velocity was 89, 94, and 76 points. It is obvious that you shouldn’t take more than 90 points of workload for your next iteration. Even if other stakeholders are crying to take their “most important task” as well.
During our planning sessions, my team always reserved some free space for unexpected bugs and technical debt—we'd rather deliver less, but with a guarantee, rather than deliver nothing.
One last thing called a burndown chart. This is a good tool that helps you analyze team performance during the iteration, such as bottlenecks and more predictable completion.
Instead of conclusion
Follow these six steps to improve delivery of the features. Keep in mind that everything starts with a good and informative description, whether you prefer the user story format or any other format of feature documentation.
Proactively work with developers and stakeholders. Initiate feature demos and Q&A sessions. This makes them feel involved in the process and helps identifying problems on early stages.
Master the art of estimation.
Track the velocity and optimize time load accordingly.
Repeat the steps on each iteration.