Scrum and XP from the Trenches - 2nd Edition Henrik Kniberg

The book can be downloaded for free from here.

Table of Content


Nokia Requirements for Iterative Development

Part One - Intro

Part Two - How we do product backlogs

Product Backlog Example

ID Name Estimate How to demo Notes
1 Deposit 5 Log in, open deposit page, deposit €10, go to my balance page and check that it has increased by €10 Need a UML sequence diagram. No need to worry about encryption for now.
2 See your own transaction history 8 Log in, click on “transactions”. Do a deposit. Go back to transactions, check that the new deposit shows up. Use paging to avoid large DB queries. Design similar to view users page.

How we keep the product backlog at a business level

Part Three - How we prepare for sprint planning

Part Four - How we do sprint planning

Why the product owner has to attend

Why quality is not negotiable

Sprint planning meetings that drag on and on…

Scrum is like any other tool – you can use a hammer to build something or to smash your thumb. Either way, don’t blame the tool.

Sprint-planning-meeting agenda

Backlog Refinement

10:30-11:30 Team time-estimates, and breaks down items as necessary. Product owner updates importance ratings as necessary. Items are clarified. “How to demo” is filled in for all high-importance items.

Sprint Planning

13:30-14:00 Product owner goes through sprint goal and summarizes product backlog. Demo place, date, and time is set.
14:00-15:00 Team selects stories to be included in sprint. Do velocity calculations as a reality check.
15:00-16:00 Select time and place for daily scrum (if different from last sprint). Further breakdown of stories into tasks.

Defining the sprint length

Short sprint Long sprint
short feedback cycle
more frequent deliveries
more frequent customer feedback
less time spent running in the wrong direction
learn and improve faster
The team gets more time to build up momentum
they get more room to recover from problems and still make the sprint goal
you get less overhead in terms of sprint planning meetings, demos, etc.
Product owners like Devlopers like

Defining the sprint goal

Deciding which stories to include in the sprint

This raises two questions:

1. How can product owner affect which stories make it to the sprint?

The product owner is disappointed that story D won’t be included in the sprint. What are his options during the sprint planning meeting?
Add D and remove C.
Reduce the scope of A.
Split the scope of A.

2. How does the team decide which stories to include in the sprint?

1) Gut Feel

2) Velocity calculations

Which estimating technique do we use?

Why we use index cards

Just make sure you are adapting the tool to your process, and not vice versa.

Definition of “done”

Time estimating using planning poker

Clarifying stories

Breaking down stories into smaller stories

Breaking down stories into tasks

Example of breaking down a story into smaller stories: Example of breaking down a story into tasks:

Defining time and place for the daily scrum

Where to draw the line

Tech stories

Transparency is one of the core values of Scrum

The relationship should really be based on trust and respect; without that, you are unlikely to succeed with whatever you are building.

Bug tracking system (Jira) vs. product backlog

Sprint planning meeting is finally over!

Part Five - How we communicate sprints

Part Six - How we do sprint backlogs

Sprint-backlog format

How the task board works

Example 1: After the first daily scrum

Example 2: After a few more days

How the burn-down chart works

This chart shows that:

Task-board warning signs





Hey, what about traceability?!

Estimating days vs. hours

Part Seven - How we arrange the team room

Seat the team together!

Keep the product owner at bay

Keep the managers and coaches at bay

As for well-functioning Scrum teams, make sure they get everything they need, then stay the hell out of the way (except during sprint demos).

Part Eight - How we do daily scrums

How we update the task board

Dealing with latecomers

Dealing with “I don’t know what to do today”

** Scrum master: OK, who wants to demonstrate the beta-ready release to us? (Assuming that was the sprint goal.)
: (Confused silence.)
Scrum master: Aren’t we done?
Team: Um… no.
Scrum master: Oh darn. Why not? What’s left to do?
Team: Well we don’t even have a test server to run it on, and the build script is broken.
Scrum master: Aha. (Adds two Post-its to the task wall.) Joe and Lisa, how can you help us today?
Joe: Um…. I guess I’ll try to find some test server somewhere.
Lisa: And I’ll try to fix that build script.

If you are a Scrum master and you find yourself resorting to the above tricks too often, you should consider taking a step back. Despite your helpful intention, you may be the team’s biggest impediment, stopping them from learning how to self-organize!

Part Nine - How we do sprint demos sprint review

Why we insist that all sprints end with a demo

Checklist for sprint demos

Dealing with indemonstrable stuff

Team member: I’m not going to demonstrate this item, because it can’t be demonstrated. The story is “Improve scalability so system can handle 10,000 simultaneous users”. I can’t bloody well invite 10,000 simultaneous users to the demo can I?
Scrum master: Are you done with the item?
Team member: Yes, of course.
Scrum master: How do you know?
Team member: I set the system up in a performance-test environment, started eight load servers, and pestered the system with simultaneous requests.
Scrum master: But do you have any indication that the system will handle 10,000 users.
Team member: Yes. The test machines are crappy, yet they could handle 50,000 simultaneous requests during my test.
Scrum master: How do you know?
Team member (frustrated): Well, I have this report! You can see for yourself. It shows how the test was set up and how many requests wee sent!
Scrum master: Oh, excellent! Then there’s your “demo”. Just show the report and go through it with the audience. Better than nothing right?.
Team member: Oh, is that enough? But it’s ugly. I need to polish it up.
Scrum master: OK, but don’t spend too long. It doesn’t have to be pretty, just informative.

Part Ten - How we do sprint retrospectives

“I’m in such a hurry to chop down trees, I don’t have time to stop and sharpen my saw!”

How we organize retrospectives

Three columns:

Spreading lessons learned between teams

To change or not to change

Examples of things that may come up during retrospectives

“We should have spent more time breaking down stories into sub-items and tasks”

Typical actions: None.

“Too many external disturbances”

Typical actions:

“We overcommitted and only got half of the stuff done”

Typical actions: None.

“Our office environment is too noisy and messy”

Typical actions:

Part Eleven - Slack time between sprints



Even Better:


Part Twelve - How we do release planning and fixed-price contracts

Define your acceptance thresholds

Importance Name
red banana
red apple
red orange
red guava
red pear
yellow raisin
yellow peanut
yellow donut
yellow onion
green grapefruit
green papaya
green blueberry
green peach

Red = must be included in version 1.0
Yellow = should be included in version 1.0
Green = may be done later

Time-estimate Size-estimate the most important items

Importance Name Estimate
red banana 12
red apple 9
red orange 20
red guava 8
red pear 20
yellow raisin 12
yellow peanut 10
yellow donut 8
yellow onion 10
green grapefruit 14
green papaya 4
green blueberry  
green peach _

Better to be roughly right than precisely wrong!

Estimate velocity

Put it together into a release plan

Importance Name Estimate
  Sprint 1  
red banana 12
red apple 9
red orange 20
  Sprint 2  
red guava 8
red pear 20
yellow raisin 12
  Sprint 3  
yellow peanut 10
yellow donut 8
yellow onion 10
green grapefruit 14
  Sprint 4  
green papaya 4
green blueberry  
green peach _

Adapting the release plan

Reality will not adapt itself to a plan, so it must be the other way around.

Part Thirteen - How we combine Scrum with XP

Pair programming

Some conclusions so far about pair programming:

Test-driven development (TDD)

In short, test automation is crucial, but TDD is optional.

TDD on new code

TDD on old code

Incremental design

Continuous integration

Collective code ownership

Informative workspace

Sustainable pace/energized work

What counts is focused, motivated hours.

Burning people out is Evil.

Part Fourteen - How we do testing

You probably can’t get rid of the acceptance-test phase

Minimize the acceptance-test phase

Increase quality by putting testers in the Scrum team

The tester is the “sign-off guy”

What does the tester do when there is nothing to test?

Increase quality by doing less per sprint

It is almost always cheaper to build less, but build it stable, rather than to build lots of stuff and then have to do panic hot fixes.

Should acceptance testing be part of the sprint?

Sprint cycles vs. acceptance-test cycles

Here’s a more realistic picture:

* The diagonal red lines in Sprint 2 symbolize chaos.

Approach 1: “Don’t start building new stuff until the old stuff is in production”

Approach 2: “OK to start building new stuff, but prioritize getting the old stuff into production”

Bad approach: “Focus on building new stuff”

Back to reality

Part Fifteen - How we handle multiple Scrum teams

How many teams to create?

Optimal team size

Synchronized sprints – or not?

Why we introduced a “team lead” role

The best managers find a way to help the team self-organize into a suitable structure rather than assign a structure top-down.

How we allocate people to teams

Specialized teams – or not?

Approach 1: Component-specialized teams

Approach 2: Cross-component teams

Rearrange teams between sprints – or not?

Part-time team members

Multitasking is a beast that kills productivity, motivation, and quality

How we do scrum-of-scrums

Product-level scrum-of-scrums

Corporate-level scrum-of-scrums

Life is too short for boring meetings.

Interleaving the daily scrums

Firefighting teams

If you isolate the other teams from fires, they won’t learn to prevent new fires!

Splitting the product backlog – or not?

Strategy 1: One product owner, one backlog


Strategy 2: One product owner, multiple backlogs

Strategy 3: Multiple product owners, one backlog per owner

Code branching

Multi-team retrospectives

work in crossfunctional teams, visualize things, deliver often, involve real users, automate your tests and release process, and experiment a lot. The basic agile principles, really.

Part Sixteen - How we handle geographically distributed teams


Team members working from home

As long as the team is clearly accountable for the product they deliver, they tend to act responsibly.

Part Seventeen - Scrum-master checklist

Part Eighteen - Parting words

About the author

Year Job
1998-2003 As co-founder and CTO of Goyada (1998-2003), experiment with test-driven development and other agile practices as he built and managed a technical platform and a 30-person development team.
late 2005 Using Scrum and XP as a tool, Henrik helped a swedish company in gaming business out of the crisis by implementing agile and lean principles at all levels in the company.
November 2006 He started writing the initial notes and it had grown into an 80-page article entitled “Scrum and XP from the Trenches”, which ultimately became this book

~~The End~~
Summarized by Chairat Onyaem (Par) @