General
Team roles
Any problems lie not with individuals but with the team as a whole.
There’s no ownership or blame within the development team.
The “master” in “scrum master” is for mastery, not for boss.
“A team can survive without a scrum master but cannot not have a product owner.”
“Middle managers are sponsors for opportunities for improvement.”
“Developers aren’t paid to take risks. Managers are.”
Product ownership
“A product owner doesn’t write user stories. A product owner is a manager.” They’re there for accountability, budgets, etc.
A product owner is not a product owner if they do not have the authority to make decisions.
Listening too much to short-term customer needs makes for a bad product owner.
Plan forward, but also in reverse, back-to-front.
Managing stakeholders
“If you promise your boss you’re going to be finished by the end of the year, you’d better be finished by March or so.”
If something’s not possible, it’s not possible. So let’s figure out what we can do.
If someone wants something new, defer them to the product owner.
Those who don’t participate will have to deal with the decisions and outcomes made by those who do.
Velocity
The product owner is the only person who should look at velocity. The team doesn’t need to know. Management shouldn’t know because they’ll just compare the team to their past output. “Tell your scrum masters.”
The burn chart should only be updated at the end of the sprint. It’s about the backlog, not micromanagement.
The burn chart puts unnecessary pressure on the dev team, which is contrary to the agile value of respect.
“Burn down engineering”
“Wherever there is fear, there is going to be cheating. Drive out fear if you want to lead.”
Track sprints. Take the average, minimum, and maximum velocities. If someone’s away or ill, throw that sprint’s number out.
Efficiency
Dr. Seuss - Beekeepers’ keepers as an analogy for inefficient org structures
Waste tower, waste snake
Each developer places pieces of Lego at the end of the day onto a Lego wall. A 2x2 block represents ¼ of a day. The blocks are colour-coded for types of work, meetings, distractions, etc. At the end of the sprint, we can visualise where our time was spent. If it’s valuable, it’s work. If it doesn’t add value, we don’t do it anymore.
“The learning is in confronting the problem and then doing something about it.”
When showing visualisations, give the context of evolution.
Lean: Value demand vs. failure demand/waste/opportunities for improvement
The easiest way to increase velocity is to decrease waste.
“Don’t stay in meetings where you have the feeling you’re wasting your time.”
Henrik Kniberg - Product Ownership in a Nutshell
There are two types of value:
- Customer value
- Reduction of risk (business risk, technical risk, cost, etc.)
Value for the business = customer value + knowledge value
When forced between reducing scope and extending time, reduce scope. That way you can still extend time later if needed.
Implementing my learnings
“Don’t start a revolution.”
Start with something doable.
At retrospective, as a team:
- Brainstorm our biggest problems
- Brainstorm what would be ideal or awesome (problem/awesome are opposites but also reality/possibility; “awesome” questions what we’ve identified as our problems to surface real issues
- Set milestones to achieving our awesome, ideal situation
- Decide what first steps I can take to achieve those milestones
Backlog
A product should be worked on by one team with one backlog. This ensures everyone is always delivering the highest business and customer value. Otherwise, one team’s highest priority could be lower than the next team’s lowest priority.
“Don’t use words like ‘epic’ unless the whole company knows what you’re talking about.”
The backlog is a queue, not a dump!
The backlog is not a list of ideas. The backlog is a list of things we really plan to do soon.
If we have 225 backlog items and we can deliver 5 per sprint, our backlog will take a year and a half or more.
When new stories come in faster than the team can deliver them, stop the backlog from growing by saying no: “It’s never going to happen, man!”
To cull the backlog:
- Gather stakeholders and the dev team
- Make sure the backlog is prioritised
- Divide it into two
- Repeat until you have three sprint’s worth of work
- Keep everything else (everything you can’t do very soon) separate
The scale of backlog items is relative to the size of an organisation’s vision.
Non-urgent bugs should go into the backlog. If it’s not urgent, chances are that there is more business value in leaving it and building something else.
Bugs are worth zero points. This discourages poor quality.
Use flags in Jira to denote one of: ready, waiting, refinement needed, etc.
Prioritisation
Product strategy
Don’t be everything for everybody. Build for the common needs. It will make for a better product and more efficient team.
Define your product well. Keep a strong vision. Bending to sales and prospects will destroy your product. Don’t put every new need or request from these stakeholders at the top of the backlog; maybe consider the absolute minimum.
Competitors will come up with new ideas. We need to be quick enough to adapt.
Go through cycles of “move fast and break things” and “move slow and fix things.”
How to prioritise
MoSCoW - Must/Should/Could/Want
- The extremes, musts and wants, come at the cost of something else. Expect tradeoffs.
- All musts are equal priority because, if they’re all required, it doesn’t matter which one you do first.
- Would you delay for it? If so, it’s not a must, it’s a should or could.
- Wants are irrelevant.
Either scope is fixed or time is fixed. One determines the other. (Use MoSCoW in conjunction with this concept.)
If everything is high priority, the only differentiator for deciding what’s next is how long things will take.
Other exercises for defining priorities:
- Time-value plot
- Kano model*
Remember to ask positive and negative variation of each question. Without asking a question’s opposite, you have biased research.
When using ranking exercises, make thinking explicit.
User stories
“User stories are waterfall.”
Stop writing [all] requirements as user stories. Ex: “As a network cable, I want to be plastified.”
The core of the story is usually a noun and a verb between “I want to” and “so that”.
Try calling user stories “things”. Like saying “product backlog items”, it will force a shared understanding of the thing when you later have to define it.
The longer and more prescriptive a story is written, the less work it is. (More qualifiers, etc.)
- “If product owners don’t write user stories, who does?”
- “No one writes user stories. No one writes anything unless the dev team decides they want to write something to remember it.”
There are no go-betweens in Scrum. There is no one collecting requirements and dictating them to developers.
Instead of using one field for the whole story, use three:
- Why? (In order to…)
- Who? (As a…)
- What? (I want to…)
Then you can group and sort by user type, motive, etc. instead of epics. You may have 200 whats, but you won’t have 200 whys. The whys are the important bit: they remind you why a customer is spending money on your product. (You can also do this with your existing backlog.)
Acceptance criteria
Keep specifics of implementation out of acceptance criteria. Implementation is the job of the developers. And in contracts, implementation becomes negotiation fodder.
“A user story doesn’t have acceptance criteria, it is acceptance criteria.”
“The details are in the code.”
Three Cs:
- Card - Story of noun + verb, defined at start of project
- Conversations - Business people and developers, during refinement
- Criteria - “Given … when … then …”, just in time, during refinement
Customer needs
Scope creep is out. If you build good software in a good way, you can encourage exploration of ideas and emergent requirements.
Customer collaboration over contract negotiation.
“You won’t win all the contracts, but you’ll win the right contracts.”
If someone wants our product to do something, they have to give us the time or send someone they trust. If it’s not important enough to give us the time, it’s not important enough to build. Don’t guess what people want.
Accelerated Business Case (ABC)
Like a kickoff meeting to create cards. Cards can and will be added, removed, or replaced.
Get users to list everything they do, chronologically. Then ask, if they could add, remove, or change something, what would it be?
This is a great way to tap into unknown user needs and wants.
Story mapping
Chronological order doesn’t matter; find categories of tasks.
Story mapping discovers user needs including efficiencies in what they’re already doing, not just new wants.
Estimation
“Estimates are always wrong. We can just try to make them better.”
“You don’t make a business smarter by using expressions like ‘guesstimate’. If estimates were right, we’d call them data.”
Good estimates come from a shared understanding between the developers and the people who envisioned the feature.
There should be no estimating during sprint planning.
Never confuse estimates with allowances.
Big estimates aren’t big because the items will take a lot of time. They’re big because we don’t know yet. We need to allow time for figuring it out.
Using Fibonacci numbers in estimation came from using real decks of cards for planning poker, 13 per suit. They wanted to reduce the numbers and realised 13 was a number in the Fibonacci sequence.
Scrum events
Refinement
Refinement should be used to estimate stories, add acceptance criteria, and find value by deciding which stories should be prioritised.
Sprint planning
“Yesterday’s weather” — don’t be concerned with previous velocities during sprint planning
Activity one
- Order cards by MVP or MoSCoW, then
- Order cards by size, then
- Put cards in swim lanes (per sprint, per release, etc)
Activity two
- On cards, annotate MoSCoW priority
- Add points estimate, but hide it; this forces the team to reevaluate, make other considerations, check dependencies, etc.
- Add functions or skills needed for item
- Fill swim lanes, then unfold estimates; the larger the gap between the lanes’ minimum and maximum velocities, the more risk or uncertainty there is in the project
- Now you have a roadmap
Enforcing a maximum number of points or amount of time per item is bullshit. Trust your devs.
If there are multiple stories of the same priority, look at other factors — skills, dependencies, etc. This is why we have sprint planning instead of just product planning.
Sprint
There’s nothing wrong with adding items to a sprint if work is done early — but make sure it’s the right work. Plan with the available team member(s) to choose manageable stories.
“Failing” a sprint is okay! Stigmatising it leads to lower productivity as developers learn to choose only how much work they can safely complete or intentionally overestimate items.
Unfinished stories go back into the backlog, not automatically into the next sprint. Always! They need to be reevaluated and prioritised.
90% done is 0% done. Maintain quality with the definition of done.
Sprint review
The sprint review includes a demo but the team should also address what they will do about feedback. (Plan actions into next print, backlog new tasks, disregard it altogether…)
Retrospective
Hide estimates of completed stories and re-estimate them in the retrospective meeting.
- Knowing what we know now, were they less or more than we thought?
- What was the difference?
- What were the factors?
- What upcoming work shares those factors? We can reduce the risk of those items by increasing estimates and/or refining further.
## Scrum board Annotate cards with notes or risks. You can use shorthand or symbols with a legend.
Don’t use status columns like “Testing” unless there’s a work in progress (WIP) limit that forces you to clear the column before bringing more work forward.
If you do have a status column, it’s better to spin it as a “ready for testing” column (without a WIP limit) because it will expose capacity problems.
Ask ourselves: Is there no other way we can represent status?
- Card size differentiates stories and tasks
- Card colour differentiates feature stories and tech stories
- Symbols for work type differentiate design and code, front end and back end, etc.
- Symbols for complexity indicate when it’s easier to do it than explain it
Explore these solutions to address problems specific to our team.
Add physical “flags” to cards to represent blockers. Leave flags on cards for the rest of the sprint so we can reference and discuss them in retrospective.
Other
Iterative development allows us to have time to do something about the “gaps”.
Scrum as a framework is the minimum — and you have to do the minimum.
Plan, design, estimate, test: Listen to whether these words are used as nouns or verbs. The value is in the verbs.
Kniberg on marginal value
Kniberg on release trains and feature toggles:
- “Unmerged code hides problems and increases technical debt.”
- Easier to test integration
- Easier to A/B test
“Resources” are people. If developers are resources, management is overhead.
There are only two answers:
- Who is responsible for…? The team.
- For everything else, it depends.
Flip the definition of done: After a sprint, what is not done? Make a list. It could include tests, documentation, training, integration… What would be awesome? What could we ship that we would be really proud of?
“Agile doesn’t have best practices. It has good practices in context.”