In my previous workplace, Agile was followed and executed seriously. Before that, I used to wonder why time constraints or measurements were necessary in technology, software development, or innovation. But in the real world, especially in a competitive market, if we cannot plan and deliver predictably, we are already too late.
Put simply: daily improvement is today’s innovation.
-
For Agile to be truly successful, a cohesive and stable team is essential. Sticking with the same team over time builds consistency, trust, and velocity.
-
Here’s how I like to define Agile in simple terms using an analogy:
Imagine a regular jogger who runs at 3 mph. If they can maintain that pace consistently over a few weeks, we know their capacity is 3 mph. With this knowledge, we can plan for future runs—like a marathon—more accurately.
-
In the same way, a team goes through a few initial sprints (or a full Program Increment, PI) to understand and stabilize its velocity. Once the team’s consistent pace is established, that becomes the team’s capacity, which helps in planning future sprints or PIs.
- In a typical 2-week sprint, suppose a team commits to 5 story points.
- Team members work through sub-tasks like coding, testing, and deployment. Let's say these activities take 2, 2, and 1 points respectively.
- As the team logs completed work, you’ll observe how those 5 points get "burned" over time—reflected visually in a burndown chart, which ideally slopes downward as work is completed.
-
One critical aspect to note is that the pointing system must remain consistent.
- For example, if 5 story points are equivalent to 2 calendar weeks or 10 working days, that should not change across teams or time.
- Consistency in estimation ensures the math behind velocity and planning holds true.
-
Story points are typically based on the Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13...) to account for increasing uncertainty and complexity.
- This aligns with human behavior—the deeper we get into a task and gain context, the more efficiently we can complete the work.
Here's how they come together in planning and execution within the software industry:
Definition:
Velocity is the measure of how much work a team completes in a sprint, usually expressed in story points or completed user stories.
Purpose:
- Helps predict how much work a team can commit to in future sprints.
- Based on historical data (previous sprints).
Example:
If a team consistently completes ~30 story points per 2-week sprint, that’s their velocity.
Definition:
Capacity is the total amount of time or effort the team has available in a sprint, often calculated in hours or ideal workdays.
Purpose:
- Accounts for holidays, PTO, meetings, and part-time team members.
- Used to ensure the team isn’t overcommitting.
Example:
If a team has 4 members working full-time in a 10-day sprint, their capacity is roughly 40 person-days.
Definition:
A visual tool that shows how much work remains over time in a sprint or PI.
Purpose:
- Tracks progress toward sprint or PI goals.
- Helps identify scope creep, blockers, or if the team is ahead/behind schedule.
Example:
The ideal burndown is a steady decline toward zero by the end of the sprint.
Definition:
A structured, 2-day planning event in SAFe (Scaled Agile Framework) that aligns multiple Agile teams on shared goals for the next 8–12 weeks.
Purpose:
- Aligns teams on business priorities.
- Establishes a shared roadmap.
- Identifies dependencies and risks across teams.
Activities Include:
- Reviewing business context and vision.
- Team breakouts to plan sprints.
- Drafting team objectives and PI commitments.
-
Before the Sprint/PI:
- Teams assess capacity (availability).
- Use velocity to estimate how many story points they can realistically commit to.
- During PI Planning, teams align their plans, define objectives, and understand cross-team dependencies.
-
During Execution:
- Teams track progress using burndown charts.
- Daily stand-ups and sprint reviews ensure transparency and course correction if needed.
- Work is delivered incrementally, validated by demos and feedback.
-
After Execution:
- Teams review actual velocity vs. capacity to improve future planning.
- Retrospectives are held to refine the process and enhance delivery.