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

With modern version control systems (like GIT), there’s no excuse not to commit often, keep the trunk clean, release often, and keep branches short-lived.

Life is too short for boring meetings.

[...] almost every sprint we found ourselves saying something like “this sprint isn’t really a normal sprint because (bla bla bla)....” After a while, we just gave up the notion of “normal” sprints. There are no normal sprints. Just like there are no normal families or normal people.

[...] it is better to have fewer teams that are too big than to have many small teams that keep interfering with each other. Make small teams only when they don’t need to interfere with each other!

Many managers don’t really understand that, when all the coding is finished, you are usually still far from production release.

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.

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

Better to be roughly right than precisely wrong!

[...] meeting must be strictly time-boxed, otherwise teams tend to spend too much time estimating too few stories.

In real life, you can’t always sprint. You need to rest between sprints. If you always sprint, you are in effect just jogging.

That applies to life too, not just Scrum! For example, if I didn’t have slack in my life, this book wouldn’t have existed (nor would this second edition, or any of my other books, articles, videos, etc.). Slack is super-important for both productivity and personal well being! If you’re one of those calendar-always-full people, try this: open your calendar and block off half a day per week, write “slack” or “unbookable” or something. Don’t decide in advance what you will do with that time, just see what happens. :o)

[...] as of 2014, the term “sprint commitment” is gone entirely from the Scrum Guide. Instead, it’s been renamed “sprint forecast”. Much better! The word “commitment” has caused so much misunderstanding. Many teams thought the sprint plan was some kind of a promise (a bit silly, considering that one of the four key values in agile is “responding to change over following a plan”). The sprint plan is not a commitment, it’s a forecast and a hypothesis – “This is how we think we best can reach the sprint goal.”

Every change you introduce has some kind of cost so, before introducing changes, consider doing nothing at all and hoping that the problem will disappear (or become smaller) automatically.

Our strategy for handling that is very simple. One person (in this case, me) attends all sprint retrospectives and acts as the knowledge bridge. Quite informal.

[...]

Important rules for the “knowledge bridge” person:

- He should be a good listener.
- If the retrospective is too silent, he should be prepared to ask simple but well-aimed questions that stimulate discussion within the group. For example, “If you could rewind time and redo this same sprint from day one, what would you do differently?”
- He should be willing to spend time visiting all retrospectives for all teams.
- He should be in some kind of position of authority, so he can act upon improvement suggestions that are outside the team’s control.

How we organize retrospectives

The general format varies a bit, but usually we do it something like this:

- We allocate one to three hours depending on how much discussion is anticipated.
- Participants: the product owner, the whole team, and myself.
- We move off to a closed room, a cozy sofa corner, the rooftop patio, or some place like that. As long as we can have undisturbed discussion.
- We usually don’t do retrospectives in the team room, since people’s attentions will tend to wander.
- Somebody is designated as secretary.
- The Scrum master shows the sprint backlog and, with help from the team, summarizes the sprint. Important events and decisions, etc.
- We do “the rounds”. Each person gets a chance to say, without being interrupted, what they thought was good, what they think could have been better, and what they would like to do differently next sprint.
- We look at the estimated vs. actual velocity. If there is a big difference, we try to analyze why.
- When time is almost up, the Scrum master tries to summarize concrete suggestions about what we can do better next sprint.
- Our retrospectives are generally not too structured. The underlying theme is always the same though: What can we do better next sprint?

Some teams do two reviews: a short public review, aimed at external stakeholders, followed by an internal review with more details and things like key challenges and technical decisions made along the way. A great way to spread knowledge between teams, and spare stakeholders from techy details they don’t care about.

The Scrum Guide recently updated the three questions to counter this:

- What did I do yesterday that helped our team meet the sprint goal?
- What will I do today to help our team meet the sprint goal?
- Do I see any impediments that prevent me or our team from meeting the sprint goal?

Notice the focus on the sprint goal, the team’s shared high-level purpose! If your daily scrums are starting to feel drab, try those questions! Or perhaps the Dan North version: ask “What’s the best ‘today’ we can have?” followed by open discussion. Whatever you do, don’t let daily scrums stay boring. Keep experimenting!

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).

That last sentence is still the best overall advice I have for managers in an agile context. Good managers are a crucial success factor, but as manager, you should try to make yourself redundant. You probably won’t succeed with that, but the very act of trying will push you in the right direction. Ask “What does this team need in order to manage itself?” rather than “How can I manage this team?” They need things like transparency, clear purpose, a fun and motivating work environment, air cover, and an escalation path for impediments.

So now we use man-days as a basis for all time estimates (although we call it story points). Our lowest value is 0.5, i.e. any task that is smaller than 0.5 is either removed, combined with some other task, or just left with a 0.5 estimate (no great harm in overestimating slightly). Nice and simple.

Even simpler: skip estimating tasks entirely! Most teams eventually learn how to break their work into tasks that are roughly a day for one to two people. If you can do that, you don’t need to bother with task estimates, which eliminates a lot of waste. Burn-down charts can still be used (if you must) – in that case, just count the tasks instead of adding up the hours.

Man-hour estimates were too fine grained; this tended to encourage too many tiny one-hour to two-hour tasks and hence micromanagement.

A quick glance at the task board should give anyone an indication of how well the sprint is progressing. The Scrum master is responsible for making sure that the team acts upon warning signs [...]

It does get rather messy as the sprint progresses, but that’s OK since it is short-lived. Every new sprint, we create a fresh, clean, new sprint backlog.

Just about all teams use avatars nowadays. Each team member picks their avatar (a South Park figure or something), prints them, and puts them on magnets. Great way to see who is working on what. Also, if each person only has like two magnets, that indirectly limits work in progress and multitasking. “WTF, I’m out of avatars!” Yeah, so stop starting and start finishing tasks!

It is important to keep the whole company informed about what is going on. Otherwise, people will complain or, even worse, make false assumptions about what is going on.

We use a “sprint info page” for this.

Sometimes we include info about how each story will be demonstrated as well.

As soon as possible after the sprint planning meeting, the Scrum master creates this page, puts it up on the wiki, and sends a spam to the whole company.

I still find tech stories to be a great pattern and use it a lot. Smaller tech stories are just embedded into the day-to-day work, while larger stories are written down and placed in a tech backlog, visible to the product owner but managed by the team. The team and product owner agree on a guideline such as “10-20% of our time is spent on tech stories”. No need for elaborate tracking schemes like focus factor or time reports, just use gut feel. Ask at the retro, “Roughly how much of our sprint capacity did we spend on tech stories, and did that feel about right?”

OK, so time is running out. Of all the stuff we want to do during the sprint planning, what do we cut out if we run out of time?

Well, I use the following priority list:

Priority 1: A sprint goal and demo date. This is the very least you need to start a sprint. The team has a goal, an end date, and they can work right off the product backlog. It sucks, yes, and you should seriously consider scheduling a new sprint planning meeting tomorrow, but if you really need to get the sprint started then this will probably do. To be honest, though, I have never actually started a sprint with this little info.

Priority 2: List of which stories the team has accepted for this sprint.

Priority 3: “Estimate” filled in for each story in sprint.

Priority 4: “How to demo” filled in for each story in sprint.

Priority 5: Velocity and resource calculations, as a reality check for your sprint plan. Includes list of team members and their commitments (otherwise you can’t calculate velocity).

Keep it simple and high-level, to take at most five minutes. Ask: “From a staffing perspective, is there anything majorly different about this sprint than past sprints?” If not, use yesterday’s weather. If so, make adjustments accordingly.

Priority 6: Specified time and place for daily scrum. It only takes a moment to decide, but if you run out of time, the Scrum master can simply decide this after the meeting and email everyone.

Priority 7: Stories broken down into tasks. This breakdown can instead be done on a daily basis in conjunction with daily scrums, but will slightly disrupt the flow of the sprint.

Task breakdown is a great opportunity to identify dependencies – like “we’ll need access to the production logs” or “we’ll need help from Jim in HR” – and figure out ways to deal with those dependencies. Maybe call Jim and see if he can reserve time for us during the sprint. The earlier you discover a dependency, the less likely it is to blow up your sprint!

What’s the difference between “tasks” and “stories”? A very valid question.

The distinction is quite simple. Stories are deliverable stuff that the product owner cares about. Tasks are non-deliverable stuff, or stuff that the product owner doesn’t care about.

Stories shouldn’t be too small or too big (in terms of estimates). If you have a bunch of 0.5-point stories you are probably going to be a victim of micromanagement. On the other hand, a 40-point story stands a high risk of ending up partially complete, which produces no value to your company and just increases administration. Furthermore, if your estimated velocity is 70 and your two top-priority stories are weighted 40 story points each, the planning gets kind of difficult. You have to choose between under-committing (i.e. taking just one item) and over-committing (i.e. taking both items).

Think of the story as a high-level problem statement, and the “definition of done” as a concrete example of how it might look like when done.

The “how to demo” description of a story can (and should) be very brief! Otherwise, you won’t finish the sprint planning meeting on time. It is basically a high-level plain-English description of how to execute the most typical test scenario manually. “Do this, then that, then verify this.”

What about a story that got almost completed during a sprint? Why don’t we get partial points for that in our actual velocity? Well, this is to stress the fact the Scrum (and in fact agile software development and lean manufacturing in general) is all about getting stuff completely, shippably, done! The value of stuff half-done is zero (may in fact be negative).

The team decides how many stories to include in the sprint. Not the product owner or anybody else.

Sometimes it makes perfect business sense to sacrifice quality in the short term – for example, because we have this super-important trade show happening after next sprint or because we just need a prototype to validate a hypothesis about user behavior. But in those cases, the product owner needs to make clear why we are doing this, and to commit to letting the team pay back the technical debt in the near future (sometimes the team will add a “clean up” story to the product backlog, as a reminder). High internal quality should be the norm, and exceptions should be treated as exceptional.

Generally speaking, a system with high internal quality can still have a low external quality. But a system with low internal quality will rarely have a high external quality. It is hard to build something nice on top of a rotten fundament.

The product owner should understand each story (normally he is the author, but in some cases other people add requests, which the product owner can prioritize). He does not need to know exactly what needs to be implemented, but he should understand why the story is there.

There’s an old and well-established template for this: “As X, I want Y, so that Z.” For example “As buyer, I want to save my shopping cart, so that I can continue shopping tomorrow.” I’m really surprised I hadn’t heard of that in 2007! Would have been very convenient. Yes, there are more elaborate templates available nowadays, but this simple one is a good starting point, especially for teams that are new to the whole agile thing. The template forces you to ask the right types of questions, and reduces the risk of getting stuck in techy details.

If the product owner has a technical background, he might add stories such as “Add indexes to the Events table”. Why does he want this? The real underlying goal is probably something like “speed up the search event form in the back office”.

It may turn out that indexes weren’t the bottleneck causing the form to be slow. It may be something completely different. The team is normally better suited to figure out how to solve something, so the product owner should focus on business goals.

ADDITIONAL STORY FIELDS

[...]

Components - Usually realized as “checkboxes” in the Excel document, for example “database, server, client”. Here the team or product owner can identify which technical components will be involved in implementing this story. This is useful when you have multiple Scrum teams – for example, a back-office team and a client team, and want to make it easier for each team to decide which stories to take on.

[...]

I tend to avoid the term “priority” since priority 1 is typically considered the “highest” priority, which gets ugly if you later on decide that something else is even more important. What priority rating should that get?

The product backlog is basically a prioritized list of requirements, or stories, or features, or whatevers. Things that the customer wants, described using the customer’s terminology.

[...] focus on delivering working code in a short timeframe means that Scrum and XP teams don’t have time for theories. They don’t pursue drawing the perfect UML model in a case tool, writing the perfect requirements document, or writing code that will be able to accommodate all imaginable future changes. Instead, Scrum and XP teams focus on getting things done. These teams accept that they may mistakes along the way, but they also realize that the best way to find those mistakes is to stop thinking about the software at the theoretical level of analysis and design and to dive in, get their hands dirty, and start building the product.