Estimating software projects is hard. Early on in the development process, you can’t precisely define the scope of a project. Because inevitably, the scope will change after development kicks off, since the team will have learned more about the project and its context by then. Still, teams have to estimate the resources they need for a project, at least approximately, before getting started.
So, how should you tackle this, then?
The traditional approach is to enter an analysis phase where you create a detailed specification of what needs to be built. But like we said, the scope of a project isn’t exactly clear before development begins. For that reason, analysis isn’t the best approach.
What is a user story?
Simple but powerful, a user story is a one-sentence description of a single functionality that needs to be implemented. It describes the user role, the function that needs to be performed, and the desired outcome. And writing these stories is an agile way to describe what we want to build.
What’s great about a user story is that it’s written in plain words. Therefore, you can write one even if you don’t have a technical background or experience in software requirements management or project management, since you can describe high-level requirements of your application without delving into technical details.
User stories are crucial for capturing the desired functionality from a user’s standpoint. They also help you communicate what, how, and why certain decisions are made, to all members of the team — even if that team consists of just one developer. By describing expectations in plain words, you also make the scope accessible to non-technical team members such as designers, QA engineers, and customer support specialists.
How to write a user story
A typical user story follows this formula:
As a <user role>, I want to <functionality description> in order to <desired outcome>
Example: As an admin, I want to create suppliers in order to be able to assign orders to suppliers and see transactions.
The user is the admin. The functionality is to create suppliers — that’s what the admin needs to do. And the final outcome is to assign orders to suppliers and see transactions, which explains why the admin needs to create suppliers in the first place.
It’s easy to confuse user stories with tasks that you write for developers. Tasks are similar to user stories, but here’s the difference: tasks usually describe only what needs to be done without providing any context, and are more about implementation. In other words, tasks describe what needs to be done in order to implement the user story: design a screen, start a background job, make a clickable button, etc. Stories, on the other hand, are high-level and simple. They provide a definition and reasoning for the tasks.
Creating a backlog of user stories would probably take you some time. You might find yourself in a situation where you don’t understand how a certain functionality that you’ve envisioned is viewed from a user perspective. That might be a sign that you need to get back to the drawing board.
Estimating with story points
Once you’ve written your user stories, you can begin estimating them.
If you have no experience in software development, this is something that you need developers to do, since you won’t know how to estimate the effort or duration of a certain piece of functionality. You can either ask the developer who will be building the application for you to provide estimates for user stories, or hire a consultant, and use their estimates as a baseline.
You might be inclined to approach estimation by estimating the amount of time needed to complete user stories. Then you’ll be able to add up the time for all user stories in the backlog, divide by the number of developers working on the project, and calculate a rough estimate of how much time it will take to complete the project.
Unfortunately, this approach won’t work — implementation always takes at least as much time as was estimated. Sometimes, it takes even more. And when user stories take more time, the whole schedule goes awry. Some stories depend on the others, which leads to more delays, forcing developers to work on multiple stories at a time. As a result, the whole estimate ends up being “off”, and the project takes two or three times longer than expected.
We need, for that reason, to acknowledge the high level of uncertainty in software projects. Rather than estimate the duration of user stories, it’s better to estimate the relative effort required to implement them.
Okay, here’s the simplest way to go about this: just score your user stories from 1 to 3. What you’re doing is ranking the complexity of the story — simple is 1, normal is 2, and complex is 3. You can even score stories as 0 for ones that require almost no effort, like changing settings or updating the design. There’s no formula for this. Just use your gut feeling and the experience of the estimator (or estimators, if you have a team of people defining story points).
The best part about story points is that they’re relative. So once you define a user story as simple, you can compare it to another to determine whether it’s of equal, lesser, or greater complexity.
Measuring a team’s velocity based on story points
You might be wondering if there’s any sense in using story points at all. After all, they don’t allow you to estimate the duration of the project or budget.
Indeed, they don’t…at least not directly. But you can turn these estimations of effort into estimations of time required by measuring how many story points your team completes in each sprint. These measurements are referred to as ateam’s velocity.
The further you are into a project, the better you’ll be able to calculate the average number of story points your team completes per sprint. And by knowing the sprint duration and multiplying it by the total number of stories divided by velocity, you can estimate the duration of the entire project.
Put simply? If you can complete three normal stories (2 points) per sprint and one complex story (3 points), then you’ll need 34 sprints to complete a project that contains 300 points.
Originally published at Hacker Noon