What you need to do
The practical activities and techniques you need to master – what to practice, what to get good at, and what to keep doing.
Backlog
Keeping the backlog lean, prioritized, and ready for development – not a graveyard of abandoned ideas. High-priority items should be well-understood with the problem clearly articulated, estimated, and small enough to complete in one sprint. Low-priority items can be less detailed. Dedicate 10% of sprint capacity to refinement. Archive or delete items that have sat untouched for 3+ months – if they mattered, they would have risen in priority. The product manager owns prioritization; the development team owns estimation and technical feasibility.
Estimation
Estimating the relative size of work items – not predicting exact hours. Story points combine effort, complexity, and uncertainty into a single relative number. The key word is 'relative': a 5-point story should be roughly twice as complex as a 3-point story. Common anti-patterns: equating points with hours, using points as productivity metrics, and treating estimates as commitments. Some mature teams drop story points entirely, forecasting using story count and historical throughput (#NoEstimates). The goal of estimation isn't precision; it's shared understanding of the work ahead.
Planning and velocity
Deciding what the team will build in the next iteration – scoped to what's actually achievable. Effective planning starts with capacity: account for individual availability, team ceremonies, maintenance work, and a 15–20% buffer for unexpected issues. Commit to roughly 80–85% of average capacity. Define a sprint goal that's outcome-driven ('increase activation rate'), not output-driven ('complete 5 tickets'). Track velocity (story points per sprint) or throughput (items per period) for forecasting, but never as a performance metric – 'increase velocity by 20%' leads to point inflation, not actual improvement.
Standups
Keeping the team synchronized without wasting anyone's time. The standup answers three questions: what did I complete, what will I work on next, and what's blocking me? Keep it under 15 minutes. The anti-pattern: standups that become status reports to a manager. The standup is for the team to coordinate with each other, not to report upward. For distributed teams, async standups work better – post updates in a Slack channel at the start of your work day. The test: if removing the standup wouldn't change how the team works, it's not adding value.
Reviews and demos
Showing working software to stakeholders – not slides, not mockups, but the actual product. Sprint reviews close the feedback loop: the team built what they planned, stakeholders see the result, and everyone aligns on what's next. Demo the feature in the real environment, not a local development setup. Let stakeholders interact with it if possible. Keep reviews under 60 minutes. If there's nothing meaningful to demo, the sprint had problems worth discussing in the retrospective.
Retrospectives
The most important agile ceremony – the one where the team actually improves. A good retrospective follows a simple flow: set the stage, review what happened, generate insights, agree on 2–3 specific improvement actions, and close with clear owners. The critical step most teams skip: follow-through. Every action item needs an owner and a target date. At the start of the next retrospective, review previous actions. Healthy teams complete 70–80% of their retrospective action items. If the same issue appears in three consecutive retrospectives, the team isn't following through.
Roadmaps
Communicating what's coming and when – the most politically sensitive communication a product manager does. Tailor the roadmap to the audience: executives want strategic themes and key milestones, sales wants upcoming features, engineering wants technical dependencies and sequencing. Never show dates unless you're confident – use 'now/next/later' or quarterly buckets instead. Be transparent about changes and explain the reasoning behind reprioritization. The roadmap is a communication tool, not a contract.
Status reporting
Keeping stakeholders informed without requiring meetings. Write async status updates that answer: what's on track, what's at risk, what's blocked, and what decisions are needed. Use a consistent format so readers know where to find what they care about. Color-code status (green/yellow/red) for quick scanning. Include metrics alongside narrative. Send updates at a regular cadence so stakeholders stop asking for ad hoc updates. Status reporting done well eliminates 50% of status meetings.
Frameworks to know
The mental models and structured approaches that guide how you think about this skill – not rules to follow, but lenses to see through.
Scrum
The most widely adopted agile framework – a structured approach with defined roles, ceremonies, and artifacts. Roles: Product Owner (what to build), Scrum Master (how the process works), Development Team (builds the product). Ceremonies: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective. Artifacts: Product Backlog, Sprint Backlog, Increment. Sprints are fixed-length iterations (typically 2 weeks). The framework's strength is its structure – it provides clear answers to 'who does what' and 'when does it happen.' Its weakness is rigidity – teams that follow Scrum mechanically without understanding its principles end up with cargo cult agile. The test: do the ceremonies produce useful outcomes, or are they empty rituals?
Kanban
A lean, evolutionary method focused on visualizing workflow, limiting work in progress, and optimizing flow. Unlike Scrum, Kanban has no sprints, no fixed iterations, and no prescribed roles – work flows continuously. The core practices: visualize the workflow on a board, limit WIP at each stage, manage flow (measure and optimize), make policies explicit, and improve collaboratively. Kanban works well for teams with unpredictable workloads (support, ops, maintenance) or as an evolution from Scrum for mature teams that find fixed sprints constraining. Many teams use 'Scrumban' – Scrum's planning and retrospective cadence with Kanban's continuous flow and WIP limits. The key insight: finishing work is more important than starting work.
Shape Up
Basecamp's alternative to Scrum – six-week cycles with two-week cooldowns. Instead of an ever-growing backlog, Shape Up uses 'pitches' – written proposals that define the problem, the appetite (how much time is this worth?), and a rough solution. The team picks from pitches at the start of each cycle and has full autonomy to build the solution within the time budget. No backlog grooming, no story points, no daily standups. If something doesn't get pitched, it doesn't get built – and that's fine. The cooldown period between cycles is for fixing bugs, exploring ideas, and recharging. Shape Up works best for product teams with high autonomy and disciplined time management.
RICE prioritization
A scoring model for prioritizing backlog items objectively: Reach (how many users will this affect in a given time period?), Impact (how much will it move the target metric – scored 0.25 to 3), Confidence (how sure are you about reach and impact estimates – scored as a percentage), and Effort (person-months of work required). RICE score = (Reach × Impact × Confidence) / Effort. The framework forces teams to think quantitatively about prioritization rather than deferring to the loudest stakeholder. It's not a replacement for product judgment – it's a tool for making tradeoffs explicit and comparable. Items with high RICE scores but low confidence should trigger research, not immediate development.
Good vs. bad
Common mistakes paired with what experienced practitioners do instead – and why the product builder approach changes the game.
The best project management I've seen doesn't feel like project management. There are no status meetings, no velocity tracking spreadsheets, no gantt charts. There's a lean backlog with clear priorities, a team that pulls work when they have capacity, WIP limits that prevent thrashing, and retrospectives that actually change how the team works. The process is invisible because it's embedded in how the team operates, not layered on top of it.
I've been on teams that practiced cargo cult Scrum – all the ceremonies, none of the principles – and teams that practiced no formal methodology but had incredible delivery discipline. The difference isn't the framework; it's whether the team understands why each practice exists and has the courage to drop practices that aren't helping. The best agile teams I've worked with are the ones that continuously shed process weight while keeping the practices that drive outcomes.
Kanban's WIP limits are the single most underrated productivity tool in software development. Every team I've introduced them to resists at first ('but I need to multitask!') and becomes evangelical within two sprints. The math is simple: reducing WIP from 5 to 3 items per person typically cuts cycle time by 40% and reduces context-switching costs. You finish things faster by starting fewer things. It's counterintuitive until you experience it.
The #NoEstimates debate misses the point. The value of estimation isn't the number – it's the conversation. When one developer says '3 points' and another says '8,' the ensuing discussion reveals hidden complexity, different assumptions, and misunderstood requirements. That's worth 10 minutes of the team's time. What's not worth the team's time is defending those estimates to management as if they were commitments.
Go deeper
Books to deepen your understanding beyond what fits on this page.
The co-creator of Scrum explains the framework's origins, principles, and practices – with real-world examples from military, education, and software teams.
Basecamp's alternative to Scrum – six-week cycles, no backlog, appetite-based scoping. Free online book that challenges many Scrum assumptions with a practical alternative.
A novel about DevOps and lean project management – follows an IT manager who transforms a failing department using Kanban, WIP limits, and the Theory of Constraints.
The definitive guide to story points, velocity, and sprint planning – covers estimation techniques, release planning, and the balance between precision and agility.
