Agile – Scrum vs Kanban

Scrum and Kanban are both popular Agile project management frameworks, but Scrum relies on rigid, time-boxed cycles with explicit roles, while Kanban focuses on continuous workflow and limiting work-in-progress to resolve bottlenecks.

Core Mechanics of Scrum

Time-Boxed Sprints: Work is divided into locked iterations where the team commits to a specific batch of deliverables.
Strict Ceremonies: Requires mandatory structural events including Sprint Planning, Daily Scrums, Sprint Reviews, and Retrospectives.
Clear Accountabilities: Relies on a Product Owner to dictate priorities, and a Scrum Master to eliminate work blockers.

Core Mechanics of Kanban

WIP Limits: Explicitly caps the maximum number of active items allowed in any single workflow column to prevent overloading.
Continuous Delivery: Tasks flow from the backlog to “Done” independently as resources allow, rather than in batched releases.
Evolutionary Change: Fits seamlessly over existing operational hierarchies without requiring an organizational overhaul.

How to Choose the Right Framework

Choose Scrum if:

You are building a complex product requiring highly disciplined planning cycles.
The project requires substantial stakeholder engagement and frequent product reviews.
Your team prefers structured routine, cross-functional collaboration, and highly concrete targets.

Choose Kanban if:

Your workflow is dictated by inbound, unpredictable operational tasks (like IT support or bug tracking).
Priorities change rapidly, demanding immediate pivot capabilities mid-week.
You want a visual aid to reveal pipeline bottlenecks without altering current team roles.

Note: Many organizations merge these models into a hybrid approach known as Scrumban, leveraging Scrum’s regular event cadences alongside Kanban’s visual WIP flexibility.

Being Agile versus Doing Agile in Scrum

Agile Scrum Team Estimation Techniques

Agile estimation techniques use relative sizing rather than exact time tracking to gauge the effort, complexity, and risk of completing tasks. These collaborative methods help Scrum teams maintain predictable delivery and realistic workloads without relying on rigid, top-down predictions.

Common Agile estimation techniques include:

1. Planning Poker

How it works: Team members use a deck of cards with values from the modified Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, etc.). The Product Owner presents a user story, the team discusses it, and each member privately selects a card representing their effort estimate.
When to use it: Ideal for detailed sprint planning and backlog refinement, especially when you need to encourage team collaboration and reach a consensus.

2. T-Shirt Sizing

How it works: Tasks are assigned sizes (XS, S, M, L, XL) based on high-level complexity rather than precise points.
When to use it: Excellent for rapid, broad-brush estimation during initial release planning or when mapping out large Epics that aren’t yet refined into granular user stories.

3. Affinity Estimation

How it works: The team collaboratively groups user stories on a wall or digital board into columns representing different sizes. Every team member can move a story if they disagree with its current size, creating a consensus through comparative grouping.
When to use it: Best suited for large product backlogs where many items need to be sized quickly in a single session.

4. Dot Voting

How it works: Team members receive a limited number of physical or digital “dots” to place on user stories they believe carry the highest complexity or effort, prioritizing stories based on the concentration of votes.
When to use it: Helpful for quick prioritization and establishing a baseline for relative difficulty among a large list of tasks.

5. The Bucket System

How it works: Similar to Affinity Estimation, various “buckets” (numbered with Fibonacci sequences) are laid out. Stories are placed in the buckets, which helps the team rapidly categorize relative effort.
When to use it: Great for medium-to-large backlogs requiring faster execution than traditional Planning Poker without sacrificing sizing accuracy.

To dive deeper into implementing these practices for your team, check out Atlassian’s Guide to Agile Estimation or explore Monday.com’s Agile Estimation Strategies.

Agile Scrum Velocity and Capacity

Agile User Story Creation for Scrum Masters; clarity, value and readiness

Mark Whitfield IT Project Manager, Brief Summary

Mark Whitfield is a highly experienced, SC-cleared Senior Project Manager and IT professional with over 31 years of experience in both public and private sectors, specializing in software development, cloud migration, and IT systems delivery.

He is currently associated with Capgemini (since 2016) and runs a project management resource website, PROject Templates.

Joined Capgemini in 2016 having worked at ascending points in software development lifecycle projects for over 31 years

Key Qualifications & Experience:

Roles: Senior Project Manager, Engagement Project Manager, Delivery Manager, and former programmer.
Methodologies: PRINCE2 Practitioner, skilled in both Waterfall and Agile (SCRUM) approaches.
Sector Experience: Extensive experience in finance and banking, including ATM software swap-outs, cloud migration (Azure, AWS, Power Platform), and POS monitoring systems.
Background: Graduated in Computing in 1990; worked as a developer (COBOL, SQL, Tandem / HPE NonStop) before transitioning to project management.

PRINCE2 Practitioner, skilled in both Waterfall and Agile (SCRUM) approaches

Professional Highlights:

Delivered major projects for clients such as Barclays, Bank of England, HSBC, Royal Mail Group, UK & Welsh Government, Heathrow, and Jaguar Land Rover.
Led complex IT infrastructure projects and business transformations.
Maintains mark-whitfield.com, offering over 200 project management templates, trackers (RAID, budget, benefit, cost etc.), and many plans for Agile / Waterfall projects including 30+ Plan On a Page (POaP) and MS Project MPP examples (click on Blog above for a summary).
Provides specialized templates for PRINCE2 7th edition and MS Project (MPP).

December 2022 – C&CA UK’s Communications & Engagement Award Winner – Cloud & Custom Applications – Capgemini UK

November 2017 – Advanced Engagement Management Course – Level 2 Exam

June 1990 – Higher National Diploma in Computer Studies (DISTINCTION – overall top) – BIHE — June 1990 – Higher National Diploma in Computer Studies, Distinction

Priorization Techniques in Agile Scrum

Prioritization in AgileScrum is the systematic process of ordering Product Backlog items to maximize value delivery. These techniques are generally categorized by their primary focus: customer satisfaction, business value and economics, or collaborative consensus.

Category 1: Customer-Centric Frameworks

These methods prioritize features based on how they impact the end-user’s experience and satisfaction.

Kano Model: Categorizes features into three main types: Basic Needs (expected essentials), Performance Features (linear satisfaction), and Excitement Needs (unexpected “delighters”).
User Story Mapping: Visualizes the entire user journey to identify the most critical paths and “skeletal” features needed for a Minimum Viable Product (MVP).
Opportunity Scoring: Uses customer research to find gaps where importance is high but current satisfaction is low, identifying high-potential opportunities.

Category 2: Economic & Quantitative Models

These data-driven techniques use formulas to balance value against implementation costs or risks.

Weighted Shortest Job First (WSJF): Prioritizes tasks by dividing the Cost of Delay (value, urgency, and risk reduction) by Job Size (effort). The goal is to deliver the most value in the shortest time.
RICE Scoring: Calculates a score based on Reach (number of users), Impact, Confidence (certainty in estimates), and Effort.
Cost of Delay (CoD): Measures the economic impact or potential revenue loss of not delivering a feature within a specific timeframe.

Category 3: Stakeholder & Team-Based Consensus

These collaborative methods are used to reach agreement among diverse stakeholders or team members.

MoSCoW Method: A qualitative technique that buckets items into Must-Have, Should-Have, Could-Have, and Won’t-Have for a specific release cycle.
100-Dollar Test: Participants are given a hypothetical $100 to “spend” on features, revealing what they value most through resource allocation.
Priority Poker: A gamified, collaborative approach where team members anonymously vote on an item’s priority level to remove bias and foster discussion.

Category 4: Structural & Visual Matrixes

These tools help teams visualize trade-offs, typically using 2×2 grids.

Value vs. Effort Matrix: Plots tasks on two axes to identify Quick Wins (high value, low effort) and Major Projects (high value, high effort) while avoiding “thankless tasks”.
Risk/Value Matrix: Balances potential business rewards against technical or project risks to decide which high-value but high-risk items to tackle early.
Stack Ranking: A “forced ranking” method where every item has a unique, linear position (1 to N), preventing the “everything is high priority” trap.

Priorization Techniques in Agile Scrum

Scrum and Agile in Projects

What is a Spike in Agile Scrum?

Agile Scrum Epic vs Feature vs User Story

Daily Planning for Agile Scrum Teams on a page

Agile Scrum Backlog Grooming & Sprint Planning

Scrum Agile Framework summary and detailed historical timeline by era and year

Scrum is an Agile framework for managing complex, innovative product development through small, cross-functional teams working iteratively in short time-boxes called Sprints. Inspired by a 1986 “rugby” approach to product development, it was formalized in the early 1990s by Jeff Sutherland and Ken Schwaber to improve team productivity and deliver value quickly.

Scrum is based on empiricism—transparency, inspection, and adaptation—and is defined by specific roles (Product Owner, Scrum Master, Developers), events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment).

Detailed Historical Timeline

The Conceptual Era (Pre-1990s)

1986: Takeuchi and Nonaka publish “The New New Product Development Game” in Harvard Business Review. They introduce the “rugby” approach—a team working together, passing the ball back and forth, to increase speed and flexibility.

Scrum Takes Shape (1990–1999)

1993: First Scrum implementation: Jeff Sutherland, John Scumniotales, and Jeff McKenna at Easel Corporation apply these concepts to software development.
1995: Ken Schwaber and Jeff Sutherland present a paper, “The SCRUM Development Process,” at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference in Austin, Texas, formally introducing the framework.
1996: Ken Schwaber and Mike Beedle refine the process, focusing on software development.
1999: Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, and Jeff Sutherland publish “SCRUM: An extension pattern language for hyperproductive software development”.

Agile and Formalization (2000–2009)

2001: Ken Schwaber, Jeff Sutherland, and 15 others create the “Agile Manifesto” in Snowbird, Utah. Schwaber and Beedle publish the first book on Scrum: Agile Software Development with Scrum.
2002: Ken Schwaber, Mike Cohn, and Esther Derby found the Scrum Alliance to provide certifications.
2004: Ken Schwaber publishes Agile Project Management with Scrum.
2006: Jeff Sutherland founds Scrum Inc..
2009: Ken Schwaber leaves the Scrum Alliance and founds Scrum.org to provide Professional Scrum accreditation.

The Scrum Guide Era (2010–Present)

2010: First “Scrum Guide” is published by Ken Schwaber and Jeff Sutherland to define the framework, often revised in subsequent years (2011, 2013, 2016, 2017).
2017: PRINCE2 Agile is published, adding governance layers for organizations using Scrum.
2020: The latest Scrum Guide (November 2020) is released, focusing on a more minimal, less prescriptive definition, introducing the “Product Goal” and changing “Development Team” to “Developers”.

Key Components of Scrum

Roles: Scrum Master (servant leader), Product Owner (backlog owner), Developers (build the product).
Events: Sprint (1–4 weeks), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Artifacts: Product Backlog, Sprint Backlog, Increment.

Scrum Agile Framework summary and detailed historical timeline by era and year