It's Story Time

You have just learned about Scrum and feel ready to run your first Sprint Planning session. But what exactly does Sprint Planning involve? How do we decide which features get built in a given sprint? What are the outcomes of a Sprint Planning session?

Before diving in, let us take a step back and look at the bigger picture. Instead of focusing on a single sprint, let us focus first on the product we are building, so we know what we are working toward across many sprints.

Every product a company builds is ultimately paid for by its users. So before any planning begins, we need to revisit who those users are. If we drift from their needs and wants, they will eventually look for a close substitute.

What are Personas?

Personas are fictional characters that are created to represent the different user groups of your product.

Personas help us understand users' needs, wants, and goals. Creating a persona clarifies who we are building the product for. Using a simplified Airbnb as an example, we can start with two personas: a homeowner and a traveler. The smaller the company, the more specific the personas tend to be. A product is usually niche at the start, but as it grows, its personas broaden to cover a wider audience. Some companies grow so large that they stop formally maintaining personas at all.

In my opinion, it is always worth revisiting personas to understand your core audience. If you stay in the game long enough, a close substitute will eventually emerge. When it does, some users will drift toward your competitor. On the other hand, if you genuinely meet the needs and wants of your core user group, they will stick around.

Take Instagram as an example. Instagram has historically targeted users under 35 who want to share photos or story moments with a specific network. When TikTok emerged (global launch 2018, after merging with musical.ly), creators who had been using Instagram for skits and short-form content flocked there because TikTok was built for them. Viewed that way, Instagram and TikTok are not direct competitors, they serve different user groups. Before then, those creators simply had no better option than Instagram.

You could argue Instagram should have identified these personas earlier and adapted. That is a debate for another day. The point: conduct user research continually to understand who your users are and why they use your product. UI/UX researchers typically own persona creation and refinement. Only after we understand our users can we plan out our initiatives.

Now that we have understood who are our users, how do we measure that the users want? In most products there is something known as a North Star.

The North Star

A North Star Metric is a single measure that best captures the core value your product delivers to users. Every team members such as designers, engineers, product managers, uses it to align decisions and prioritize work.

The North Star is not a vanity metric like total downloads or page views. It reflects genuine user value. For Airbnb, the North Star might be nights booked. For Spotify, it could be time spent listening. The metric moves when users are getting real value and it stalls when they are not.

Why does this matter for planning? Because it gives every initiative a clear test does this move the North Star? If an epic does not contribute to it, either the epic is low priority or the North Star needs revisiting.

Setting a North Star is not a one-time exercise. As your product evolves and your personas shift, revisit it. A startup's North Star is often narrow and specific. A mature product may graduate to a broader metric as its audience grows.

Once the team aligns on a North Star, they can break down the work needed to move it starting with initiatives.

Breaking down the Initiative

Whenever a team sets out to build something meaningful, they need a game plan. One popular structure is initiatives, epics, stories, tasks, and sub-tasks. A user-centric breakdown where each completed item delivers something a user can do.

An Initiative is a product goal. It can be broken down into multiple epics.

An Epic breaks an Initiative into smaller parts. It contains a collection of user stories, something a user can do with the product once the epic is complete.

User Stories are requirements written from the perspective of the end user.

A Task is a breakdown of a story into smaller pieces of work.

A Sub-task is a breakdown of a task.

Popular project management tools include Jira, ClickUp, Notion, Linear, Asana, and Monday. Each has strengths and limitations beyond our scope here. In my experience, a company is far better off standardising on one tool. Running Scaled Scrum where one team uses Notion and another uses Jira quickly becomes a nightmare to manage.

Before planning begins, the team must align on development standards. In product-centric teams, this alignment is captured in the Definition of Done.

Definition of Done

Definition of Done is the acceptance criteria for a particular type of user story or epic.

A caveat, according to the Scrum Guide, the Definition of Done should apply uniformly to every increment. In practice, a Design task has very different acceptance criteria from a Developer task or a Quality Assurance (QA) task. Ultimately, the team must agree on what "done" means for each type of task, so that a Done label carries the same expectations for everyone.

A Design task might be to run A/B testing on two designs. Its Definition of Done could include:

An example of a QA task might be to investigate a bug report filed by a user. Its Definition of Done could include:

An example of a Developer task might be to build a login page. Its Definition of Done could include:

Sprint Planning

Now that we have covered the terminologies, let us talk about the Sprint Planning session itself.

At the start of the meeting, the team decides on the what. The Product Owner picks items from the backlog for the team to work on and sets the initial sprint goal. These items are usually chosen because they relate to initiatives or epics from the previous sprint, or because they kick off a new one.

The development team then plans out the how, the scoping and specifications needed to deliver the sprint goal. This must be a negotiation. If the work is too large, the "what" needs to be adjusted. Ultimately, the scope must be manageable, and the team must agree that the selected items can meet the Definition of Done by the end of the sprint.

Once the sprint goal is finalized and the scope is locked, the team decides the who, meaning who takes which task. This is done purely by the development team.

"The how" is where most disagreements emerge. Don't be alarmed when discussions turn into negotiations or tensions rise — good teams harness that friction to build a better product. Everyone is pushing for the best outcome, and what seems like a straightforward task quickly grows complex when you factor in doing it right and planning for the future. My advice: stay pragmatic. Hitting scaling issues is a good problem, it means users love what you built. That said, make sure the product can handle the load for at least the first 3 months after launch.

Although it is standard practice for the Product Teams to decide on the timeline, some companies take a top-down approach where management effectively says, "I do not care how, just get it done by this date." You build products the fastest way possible, almost like bootcamp. For short-lived projects or products serving a small user base for a year or two, you will probably be fine. But when maintenance and enhancements arrive, reading the code can feel like pulling teeth, the hallmark of technical debt.

In my opinion, the top-down approach is one of the drivers behind the Great Resignation. Maintenance becomes so painful that the original developers leave, the company hires replacements, and the cycle repeats.

Impact of AI

AI is reshaping the entire initiative-to-task pipeline, and teams that lean into it are moving significantly faster.

Starting at the top, persona creation and user research, once a weeks-long exercise can now be bootstrapped in hours. Tools like Miro's AI persona generator synthesize analytics, support tickets, and survey data into structured personas. That said, the Nielsen Norman Group cautions that synthetic personas cannot fully replace the empathy that comes from real user interviews. Use AI to accelerate the process, not to skip it. My recommendation is for AI to generate test personas but get people to validate.

Further down the pipeline, AI is changing how teams write and manage stories. Jira's Atlassian Intelligence can generate structured tickets from plain descriptions, auto-assign priority, and answer questions across Jira, Confluence, and connected tools. ClickUp's Sprint Planning Agent scores backlog items against team capacity and proposes sprint scope, reportedly cutting planning time by 30 to 40 percent.

More notably, many teams are moving away from heavy project management tools entirely. Linear has gained significant adoption because it is fast, opinionated, and AI-native, its triage and summarization features work without configuration. A growing number of teams now manage backlogs in plain markdown, either in GitHub Issues or purpose-built tools like Backlog.md. The reason is practical: LLMs parse markdown cleanly, tasks live in the same Git repository as the code, and the entire history is version controlled. GitHub has even published a guide on spec-driven development — writing requirements in markdown and letting AI agents execute against them.

On the development side, AI coding assistants like GitHub Copilot, Cursor, and Claude Code are compressing delivery timelines in ways that make traditional story point estimation feel outdated. Estimates that assumed three days of developer effort are being completed in one. Teams are starting to question whether velocity, as a concept, still means what it used to.

The net effect is that the overhead of planning is shrinking. Personas get drafted faster. Backlogs get groomed automatically. Stories get written from a prompt. What remains, and what AI cannot replace is judgment, knowing which initiative to pursue, what the North Star actually means for your users, and whether the sprint goal serves the product or just fills the calendar.

Conclusion

To wrap up, we have covered a lot about product planning. Personas help you understand who you are building for. The North Star keeps every initiative honest. The initiative-epic-story breakdown turns a product vision into actionable work. The Definition of Done ensures the team agrees on what finished actually mean and Sprint Planning is where all of it comes together into a shared commitment.

AI is accelerating every part of this process, from research to execution. The fundamentals, however, remain the same, understand your users, set a clear direction, break the work down, and ship incrementally. The teams that move fastest are not the ones who skip this process, they are the ones who have made it second nature.

The next article focuses on the "the how" portion of Sprint Planning, and why a seemingly simple task is often more complex than it looks. This is always starts with the database.