Scrum Flashcards
Backlog Refinement meeting
estimation of effort; clarification of requirements; and decomposition of large PBIs into smaller ones (epics to user stories).
INVEST
I = ?
Independent:
Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.
INVEST
N = ?
Negotiable:
A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.
INVEST
V = ?
Valuable:
A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.
INVEST
E = ?
Estimable:
A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience.
INVEST
S = ?
Small:
Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.
INVEST
T = ?
Testable:
A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.
SMART
S = ?
Specific:
A task needs to be specific enough that everyone can understand what’s involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story.
backlog
An accumulation, especially of unfinished work.
SMART
M = ?
Measurable:
The key measure is, “can we mark it as done?” The team needs to agree on what that means, but it should include “does what it is intended to,” “tests are included,” and “the code has been refactored.”
SMART
A = ?
Achievable:
The task owner should expect to be able to achieve a task.Aanybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.
SMART
R = ?
Relevant:
Every task should be relevant, contributing to the story at hand. Stories are broken into tasks for the benefit of developers, but a customer should still be able to expect that every task can be explained and justified.
SMART
T = ?
Time-boxed:
A task should be time-boxed: limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help. If a task is harder than expected, the team needs to know it must split the task, change players, or do something to help the task (and story) get done.
Sprint Planning meeting
Creating the Sprint Backlog; dividing SBIs into smaller tasks; and assuring a feasible workload.
Daily Scrum meeting
What did I do yesterday? What will I do today? What impedes me?
If a side topic comes up, postpone it until after the meeting.
