Skip to content
tezvyn:

Agile & Scrum

Scrum, kanban, sprints, team velocity, shipping culture

167 bites

Test yourself: Top 30 Agile & Scrum concepts questionsMultiple choice, with the correct answer and why it is correct on every question. Free, no sign-in.

Concepts in Agile & Scrum, page 3

Job Stories: Focus on Motivation, Not Persona
intermediate2 min read

Job Stories: Focus on Motivation, Not Persona

A Job Story shifts focus from *who* is doing something to *why*. It frames work around a situation, a motivation, and an outcome. Use it when a user's context is more important than their persona. The footgun is simply rephrasing a user story.

intermediate2 min read

Personas: Build for a Specific 'Who', Not a Vague 'Everyone'

Personas give your team a shared user understanding by creating a fictional, yet realistic, character profile. They guide feature prioritization and design decisions by focusing on a specific "who."

intermediate2 min read

Relative Sizing: Estimate Effort, Not Hours

Relative sizing compares work items to each other instead of assigning absolute hours. A team agrees on a baseline task and estimates others as 'larger' or 'smaller' relative to it, often using story points. The footgun is mapping points back to hours.

Buy a Feature: Prioritize by Making Customers Spend
advanced2 min read

Buy a Feature: Prioritize by Making Customers Spend

Buy a Feature turns prioritization into a game where customers spend a limited budget on their desired features. It's used in product planning to force trade-offs and reveal true value.

advanced2 min read

Cost of Delay: Quantifying the Price of Waiting

Cost of Delay puts a price tag on waiting, quantifying the value lost for every week a feature isn't shipped. It helps prioritize work by its economic impact, not just effort.

Impact Mapping: From Business Goals to Code
advanced2 min read

Impact Mapping: From Business Goals to Code

Impact Mapping is a visual roadmap that connects business goals directly to features, forcing you to answer "Why?" before "What?". Use it to align stakeholders on a new vision or prioritize a backlog. The footgun is starting with features and working backward.

easy2 min read

Information Radiator: Your Team's Public Billboard

An information radiator is a large, public display that broadcasts key project info to anyone walking by. It's used for build statuses or task boards to keep the team aligned without meetings. The footgun is cluttering it until it becomes ignorable noise.

easy2 min read

Timeboxing: Fix the Time, Flex the Scope

Timeboxing fixes the duration for a task, not the scope. You work for a set period and then stop, forcing focus and preventing endless work. It's the core of Agile sprints and daily stand-ups. The footgun is treating it as a hard deadline to cram.

Continuous Integration: Catching Bugs Early
intermediate2 min read

Continuous Integration: Catching Bugs Early

Continuous Integration (CI) treats code merging like a continuous stream, not a big-bang event, to keep the main codebase stable. On every commit, an automated system builds and tests the software to catch issues immediately.

intermediate2 min read

Feature Toggles: Decouple Deployment from Release

A feature toggle is a runtime switch that lets you ship dormant code and activate it later, decoupling deployment from release. It enables canary rollouts and A/B tests.

advanced2 min read

Emergent Architecture: Build Just Enough, Just in Time

Emergent architecture lets design evolve as you build, prioritizing adaptation over upfront planning. It's used in agile teams where requirements are unclear.

advanced2 min read

Continuous Delivery vs. Deployment: The Final Step

Continuous Delivery automates releases to a staging environment for a manual go-live decision, while Continuous Deployment automatically pushes every passing build to production. Use Delivery for business-timed releases; use Deployment for maximum velocity.

PDCA Cycle: The Scientific Method for Business Improvement
easy2 min read

PDCA Cycle: The Scientific Method for Business Improvement

The PDCA cycle is the scientific method for business: Plan a change, Do the experiment, Check the results, and Act on the findings. It's used to refine manufacturing or improve software cycles.

easy2 min read

Retrospective Prime Directive: Assume Positive Intent

Assume everyone acted with the best intentions given their context. The Retrospective Prime Directive creates psychological safety for a blameless discussion, focusing on systemic issues, not individual fault.

Start, Stop, Continue: A Simple Action-Oriented Retrospective
easy2 min read

Start, Stop, Continue: A Simple Action-Oriented Retrospective

This retrospective turns feedback into action by asking what to start, stop, and continue doing. Teams use it after a sprint to improve processes and collaboration. The footgun: the 'Continue' list can become a long praise session, losing focus on improvement.

Cumulative Flow Diagrams: Spotting Workflow Bottlenecks
intermediate2 min read

Cumulative Flow Diagrams: Spotting Workflow Bottlenecks

A Cumulative Flow Diagram is a geological cross-section of your project, showing work moving through states over time. Agile teams use it to spot bottlenecks by seeing where tasks pile up. The footgun is misinterpreting a widening band as a failure.

Fishbone Diagram: Mapping Problems to Root Causes
intermediate2 min read

Fishbone Diagram: Mapping Problems to Root Causes

A fishbone diagram maps a problem to its potential root causes. It's a structured brainstorming tool used in retrospectives or post-mortems to explore *why* something happened.

SMART Goals: From Vague Hopes to Actionable Plans
intermediate1 min read

SMART Goals: From Vague Hopes to Actionable Plans

SMART criteria turn vague hopes into concrete plans by forcing goals to be Specific, Measurable, Achievable, Relevant, and Time-bound. It's used in project planning and performance reviews.

intermediate2 min read

Radical Candor: Care Personally, Challenge Directly

Radical Candor is a feedback framework that combines caring personally with challenging directly. It's used to give clear, kind guidance—both praise and criticism—that helps people grow.

The 4Ls Retrospective: Loved, Loathed, Longed For, Learned
intermediate2 min read

The 4Ls Retrospective: Loved, Loathed, Longed For, Learned

The 4Ls retrospective is a structured way to capture a team's feelings after a project. It asks what they Loved, Loathed, Longed for, and Learned to create an action plan. A common pitfall is only focusing on negatives, missing key insights from the other Ls.

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles