Can you explain Sprints and Story Points in simple terms?

Can you explain sprint and story points in simple terms?

- Sheena Mclean, Aspiring Product Manager

We'll need to go back in the history of how we built software back in the day.

📖 In the history books

Software teams used to spend 1-2 years building software and selling them on physical devices like compact discs (CDs). With the increasing popularity of the internet, companies began moving their software online, which means they can deliver their software more frequently.

Remember these on the shelves of computer stores?

You will see that we do things now because they are bound to an old way of thinking, which is to use the underlying frameworks and processes used for creating large software delivered on CD ROMs.

There are many moving parts to developing and selling these software products, such as coordinating with product & engineering, marketing, docs, and sales departments. The result of this is a product or feature launch.

The Executive Leadership Teams (ELT) need a timeline of what can be built and delivered so they can start monitoring whatever metric is essential to them at that time. Based on the stage or size of the company, this could be profits, revenue, or even just sign-ups. But the gist is that they must predict that the input will have a specific result.

It comes down to budgeting their expenses.

The Management Teams, whether they are VPs, Directors, or Line Managers, must fall in line with meeting these predictions. They are bound by the rules of how companies manage their finances, such as planning around quarters.

So when we're building products and features, they require estimates of those deliverables because they have to budget accordingly. As you'll learn, story points are something we made up to avoid giving a deadline.

It was almost like a trickster move to try and fool management and make them feel good about the "plans".

But we were still bound by the laws of time, so we turned it around and gave them a deadline by saying, "here are some things we may be able to deliver within this time frame," which we refer to as a sprint.

Maybe it was named this way because instead of running a marathon, we ran a sprint?

💽 The not-so-modern world

What I wrote about in the history section still happens to this day. There are teams still doing deadlines (sprints) and estimates (story points) in both small startups to large enterprises because that's what they come into the industry and see. We tend to follow traditions blindly.

So I will explain how story points and sprints were used back in the day so you can understand why "modern" teams operate the way they do.

The title and roles are renamed, but the work is the same. As a Product Manager, however, you'll be overseeing the whole process end to end.

🔎 Research

Business Analysts (BA) would conduct their research and put together a set of requirements of what needs to be developed. Their research consists of talking to users and stakeholders and conducting market research.

The BA works with a Project Manager (PjM) and sometimes a Product Owner (PO) to plan and execute product development.

A company usually has multiple projects in the pipeline, requiring some portfolio management; this is when they'll have a PjM.

The modern tech company combined these three roles into the Product Manager (PM) role and reduced the workload from managing many projects to just a few.

📝 Planning

The planning process for the teams is an integral part of estimations and budgeting.

The PM works with the Software Developers (SDE), QA Testers, and Designers to break down these requirements into manageable chunks.

For the PM to plan properly, they need some form of estimation of these deliverables so they can report this up to their managers and laterally, meaning PMs from other teams.

But prior industry knowledge taught us that estimating software development work should never be done using time. There are always unforeseen issues. So we made up new alternatives called Story Points. This has many variations, such as saying the work is small, medium, or large, or some teams use numbers instead of a unit, like hours or days.

We would factor in the effort needed by the designers, developers, and testers into these estimates.

The whole point of story points is to just avoid pointing management to dates.

This breakdown and planning happen in what some companies still refer to as planning meeting today.

It was the most boring thing in the company for everyone because we all know that none of this ever worked out as predicted. But some people had brilliant ideas for making it fun, such as using Planning Poker.

🎨 Design, Development, Testing

The designers come up with a prototype; then the engineers build it, then it goes to QA to ensure it meets the requirements. This is the typical output of a sprint, working software in the hands of users.

This step-by-step process could take weeks or months before it moves from one stage to another, depending on how the teams are structured.

If there is a handoff of the work from one person or team to the other, the industry refers to this as waterfall development, but some teams can shrink the time each person takes by having them work together and call it Agile.

Some teams split the research and development process into Discovery and Delivery, which is still hand-offs like this:

Be on the lookout for those processes; they will prevent you from getting results quickly to defend your job position. The team should strive to operate as one, such as something like this:

The term cross-functional teams came from here when they realized that a single team must manage the work end to end to cut down the time to market. Breaking down silos is the first step to helping a product team demonstrate value and gain goodwill with executives.

Frequent communication is required in the team to break silos, which will override all vanity metrics, such as velocity and burn-down charts. The people must be placed over processes according to the Agile Manifesto, a very important document to be familiar with.

But they try to put this frequent communication into a process called Daily Standups, coming from a framework called Scrum. If they talk about the wrong things, then it makes all these processes vanity.

If the output of the sprint is to have working software in the hands of users, then the outcome is to measure the impact of software on the user.

📊 Measuring real things

You will hear about "Outputs vs Outcomes" from experienced product management folks. It requires a change of thinking, one of your biggest battles as a PM; you must change beliefs.

The whole purpose of Agile is so that the business can build and put a product in the hands of users. Then measure and analyze their behavior to learn what tweaks they need to make to sell to more users.

Read more about Build, Measure, Learn with Lean Experimentation for an idea of how some modern companies are structuring their processes.

Unfortunately, many teams are not measuring, so they are not learning anything. Without a proper product research stack, which should contain analytics, everyone operates blindly. They will celebrate the number of features released instead of how the features are helping their users and therefore driving revenue.

The first action for anyone joining a product team is to ask questions about product usage. If there is no analytics, set one up and start building your dashboards. Find out how many people are clicking on your features and why.

Get the engineers involved in research and testing so they can help you solve for outcomes instead of being a feature code monkey.

When you land a PM role and get down to the real things, you will see that Sprints and Story points are the least of your concerns and may not even need them. They are legacy processes people try to hold unto from the old world, which can hinder reacting to your analytics data.

As teams mature, they drop the sprints and ship and learn daily without waiting on a sprint to finish.