Attendees in Kitchener Waterloo – collaborating on building their Story Maps.

Story Mapping is a simple tool to help you visualize your Product Backlog. The traditional Product Backlog in Scrum is a real improvement over traditional methods for tracking and understanding the work ahead. However its still a long To Do List which has some issues:

• It’s hard to see the forest for the trees.
• It’s easy to miss important items in the morass of detail.
• It’s hard to prioritize well since we can’t see the big picture.
• It’s not explicitly focused on the user needs.

In other words, flat lists become confusing as the Product grows in size and complexity.

Story Mapping is a tool to help overcome these issues by helping the team visualize the needs of the end-users. Along the top we write out all the “User Needs”. On the Y-axis we create the Stories for each “Need” or task. Some “User Needs” aren’t of interest in the current release – so they might get no Stories. Other needs have a number of things that need to be done for them – so they get many Stories. In addition, each user gets their own map.

The key here is that the map acts as a tool to help organize the Stories. The map helps us spot gaps in our product and helps us discover the priorities. However, most importantly Story Maps help start conversations among team members about what we’re building.

The files below are from a series of Story Mapping workshops that I’ve facilitated in Montreal, Toronto and Kitchener-Waterloo this past year. If you would like to bring Mark into your company to facilitate a Story Mapping Workshop or teach a Product Owner course please email: courses@agilepainrelief.com

The files make the most sense if you’ve attended the workshop

• StoryMappingWalkThrough - the keynote presentation I run in the background.
• Story Mapping Basics - the basic introductory handout that all attendees get. It outlines some of the basic ideas behind Story Mapping and provides the core scenario for the exercises
• Julia Persona and Rob Persona - the personas that the audience gets to use for their exercises.

While working on the FedEx 2-day shipment story Martin discovers some very crufty code in the Foobar class. He doesn’t need to work in the class to complete the story, nor can he see it causing any bugs right now. He doesn’t want to ignore the issue so he grabs an index card and writes “Foobar class is very crufty and it will slow us down later”.

Later in the day the following conversation occurs:

Martin: “We need to rework the underpinnings of the Foobar class so that we can work faster.”
Product Owner Sue: “Martin, why is that important? Help me see that.”
Martin: “It’s slowing us down. Every time we work in Foobar we spend an extra 20 minutes just trying to understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect.”
Jane: “Can I trust you? Will this be the last time I ever hear about the Foobar class? Where should I put this is in the Backlog?”
…

Analysis

As we can see, there are several problems at play here:

• We’re expecting Sue (the Product Owner) who is the business domain expert to make technical decisions.
• Martin is making promises they can’t guarantee: “Give me 5 days and Foobar will be perfect.”
• User Stories must deliver real value to actual users.
•  Making this problem a User Story pretends this work has real value, but we’re doing it because we weren’t really done with the original work in the first place.

The Product Owner should be focusing on work that affects the actual Users or other Stakeholders, not technical issues inside the system we’re building.

Instead of bamboozling the Product Owner I find it more effective just to pay an ongoing tax in the range of 15-40% (depending on the state of the code base) and then maintain a separate list of technical impediments/items.

Such a list would include notes like the Foobar class that needs simplifying; tasks such as configuring a CI server or upgrading a test machine, or anything else that the team is doing to help themselves. I wouldn’t bother including small refactorings (less than an hour or two of work); I just do those and get them finished

In addition, issues like the Foobar class are best addressed when the team is already working in that part of the code or the issues are causing problems elsewhere.

If for some reason you really, really, think you must have it on the main Product Backlog (for reasons I can’t see) then don’t bother writing a User Story. Not everything in the Product Backlog needs to be or wants to be a User Story.

To be clear – the work must be made visible; just don’t try to bamboozle the Product Owner into prioritizing it.

Story Take Two

Martin writes up an index card for the Foobar class and posts in the ‘Technical issues’ list. Since it’s close to lunchtime and everyone is already getting ready to leave, he grabs Kirby and Doug. They debate the priority compared to other issues and decide that upgrading the CI server to get faster builds is more important. They point out to Martin that “Foobar” is in a rarely-visited portion of the code.

Other sources:

“As a Developer is not a Story” – Bill Wake
“Technical Stories: We don’t need ‘em” – Ron Jeffries
“Technical User Stories” Ariel Valentin

Credit: Gerard79 – http://www.sxc.hu/photo/1008231/

The Definition of Systems Thinking from Wikipedia is:

the process of understanding how things, regarded as systems, influence one another within a whole. In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization “healthy” or “unhealthy”.

When working with Agile teams System’s Thinking is an excellent tool to help you diagnose behaviours/issues. An example – despite repeated discussions about the affects of interruptions and the cost of context switching you notice your team members are responding to low priority tech support issues within five minutes of their arrival. This in spite of an SLA (Service Level Agreement) that says low priority items need only be responded to within 48 hrs. You do some research and find that in the past people have received good performance reviews and bonuses based in part on how quickly they responded to support. Further digging reveals that the bonuses were put in place because three years ago support issues where often ignored. You’ve just discovered some of the elements of Systems Thinking. For some time I’ve felt that the Agile community lacked a modern, well-written clear source on System’s Thinking.

Now Scott Fortmann-Roe and Gene Bellinger are working on an e-book and p-book project: Beyond Connecting the Dots. The project will develop an extensive and accessible book on Systems Thinking and System Dynamics. With topics ranging from introductory and conceptual ideas all the way to highly technical modeling details, it will be suitable for beginners as well as advanced readers, especially those who want to develop their skills further.

An especially interesting part of the project is the exciting technology we developed to enable the eBook version to be a “living” book. Models and exercises discussed in the book will be embedded directly in the eBook – allowing you to experiment with the models on the exact same page where you read about them.

We’re really excited by this technology. You can check out a video demo of the technology at:

http://www.kickstarter.com/projects/605480326/beyond-connecting-the-dots

Help make this a reality and become a supporter at KickStarter.

If five of my readers sign up at least the $25 level I will double my own contribution. If ten of you do, I will triple it. For fifteen I will quadruple my original contribution.

Let’s make this happen!

Distant communications are never as good as face to face.

In the past week Yahoo has said that its employees must work in a Yahoo office by June. The stated goal is to bring people together to increase collaboration. In addition, comments on Quora suggest that current and former employees feel the old work from home policy was badly abused – with Fridays being known as a “no work day”.

Please appreciate that as I others write we have no special insight into what is happening at Yahoo. In addition sometimes when you’re trying to change an entrenched organizational culture its necessary to deliver a shock to overcome inertia.

Reaction in the press castigates Yahoo, (e.g.: “A Giant Leap Backwards”, Jason Perlow says: “Yahoo Fix Your Culture and get Better Telecommuting Tools”) saying, that remote work is the wave of the future, and knocking Yahoo for not embracing it.

From the Principles page of the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Even though its already 12yrs old the statement still holds true. Electronic tools are still along way from sharing body language and emotion that face-to-face interaction provides.

For effective Agile teams remote work shouldn’t be the norm. Remote work increases the productivity of one team member, but reduces the productivity of the whole team due to limited collaboration opportunities and increased communication costs. In addition telecommuting disconnects people from the team. The key point: remember the goal isn’t to optimize the productivity of the individual but the productivity of the team(s).

On the face of it, asking employees to work in the office is a good thing. What’s missing is that it’s unclear whether people who’re moved into offices will be integrated into team spaces that will help face-to-face conversations to happen. Or will they be jammed into productivity-draining cube farms?

Human Impact

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Another Agile Manifesto Principle.

As described in the press, there is no flexibility; starting in June all remote work will cease. For some this will involve changing their childcare arrangements, while others apparently will have to relocate. Some of these people joined Yahoo on the understanding that they would be working from home; for these people their job has just changed quite radically.

All of these things would be seem to be de-motivating and so weaken engagement.

Implementation

Based on the leaks to AllThingsD (“Physically Together”) this change appears to be have been handed down from the top. I suspect the reality is more complex. Rather than suggest what should have happened at Yahoo, it’s interesting to consider other ways of having made a change like this.

Taking away choices and options that people have had for a while can be demotivating. What strategies are there for engaging them in making a change?

Option #1

State the Goal: Increase collaboration and face-to-face time. Make clear the constraints; electronic tools (Skype et al) aren’t classed as face-to-face time.

Make a rule that all new hires are expected to work in a Yahoo office. Ask existing employees to commit to coming into the office 2-3 times a week, the days can be determined by each team to meet their needs.

Experiment: Run this as an experiment; after 3-4 months you ask teams to evaluate how the experiment is going. They’re expected to improve their team approach and working agreement to continue to improve on the goal.

Option #2

State the goal and constraints (as in Option #1)

With smaller organizations let the teams experiment on their own and let them decide how to meet the to goal. Every six weeks engage the teams to find out what approaches are helping to improve face-to-face time. Share the information with other teams.

With a larger organization it’s not practical to let the teams self-organize to find the solution. In this case the teams should be provided with options and some degree of flexibility.

People have greater engagement when they can choose. They also gain from knowing there is flexibility; even if they never make use of it.

These options would be messier and bit a slower to implement but they would go a long way to making people feel like they’re part of team as a opposed to being simply told what to do.

Summary

If the goal was to shock the system and move it make it clear that the status quo can’t continue the policy will probably have the desired effect.

If the goal is an increase in productivity through co-location I wonder if it might have the opposite effect in the short term.

Qualifying to be a Certified Scrum Trainer is a long and sometimes arduous process. As part of that process Candidates seek out endorsements and mentors the past year I’ve seen the number of requests go up and I wanted to make my expectations explicit. As you read these notes, bear in mind that they’re simply written words; and as a result I won’t do a perfect job of getting the points across. In addition, it’s worth keeping some Manifesto statements in mind: “Individuals and Interactions over Processes and Tools” and “Working Software over Comprehensive Documentation”.

Finally, Transparency, Openness and Honesty are key Agile principles.

Certified Scrum Trainer Vision

When I qualified as a CST I was given this vision statement which I still find to be a valuable reminder:

A CST is an ambassador of Scrum. He or she will:

• have a solid understanding of the Scrum framework, a deep understanding of the principles and values that are the foundations of Scrum, and clarity on what belongs to Scrum and what is an extension or complement;
• have extensive experience of implementing and/or coaching Scrum inside organizations;
• be active in the wider Scrum community through actual and virtual interaction with other Scrum and Agile thinkers and practitioners;
• have training experience beyond Scrum; be willing to explore new ways of working and be committed to continuous improvement.

How do I measure these criteria? (These notes are not exhaustive, I’m open to finding other approaches).

Knowledge of Scrum

I need to see a deep understanding of Scrum which has evolved over a period of time. This often happens through blog posts, forum comments, etc. Some of this can be discovered through one-on-one conversation; but before I invest a lot of time I need to know that the candidate knows Scrum well.

Nobody will know everything; but I’m looking to see that a person has Scrum in their DNA and isn’t just repeating back one of the books on the subject.

NB: This isn’t a role you try to take on 3-4 years into your Agile journey; nor is it something that happens automatically after being a CSP.

Coaching and Implementing Scrum

I need to see that you’ve done Scrum with more than just a few teams at one company. I want to hear about your experiences in a variety of situations. In addition, I need to hear when it didn’t work, what failed and what you learned from it. It’s easy to talk about our successes implementing Scrum. I want to hear about the hard parts as well. In addition to taking your word for it, I need to be able speak directly to your clients and their teams about their experience with you. Don’t worry, I have no interest in trying to steal your clients from you.

Community

As Certified Scrum Trainers we’re expected to do more than just run our businesses. We’re also expected to help grow the Scrum Community. There are a myriad of ways to do this; participate in mailing lists – at minimum the Scrum Alliance’s own list; participate in LinkedIn groups; help organize your local Scrum/Agile user group; help with a local Scrum/Agile event or conference; act as a reviewer, stage producer etc. for a major conference.

When I look at your track record I want to see a sustained commitment over a number of years. When I see people who’ve only participated in the community for six months to a year, I wonder if they will disappear as soon as they’re approved as CST’s.

Training Experience and Style

After doing this for a number of years I believe that Scrum isn’t something that you learn from a PowerPoint presentation. Additionally, I’ve found that the more words there are on a slide, the less people learn. As a result I’ve moved to an Exercise-focused, attendee-driven style of training: “Training from the Back of the Room” aka brain focused learning techniques. If your training is full of lectures and text on slides then we will not be a good fit, and I will recommend you look elsewhere for an endorsement.

I need to a see a history of your training experience; and you need to give me an idea about how it has evolved. I’m not looking for feedback forms or anything else like that;  I just want to see how you have evolved.

To help me see your style I like to collaborate on building something (i.e. a new module) that we can both gain value from. Along with creating the module that you will facilitate/present it also allows me to see how you work. My goal is to deepen the relationship and build the trust required for me to surrender my class to you for a few hours.

Co-training is the best way to prove your training/facilitation abilities. It allows me to see directly what happens when you’re in front of a room and to see how you can work with your attendees. If that isn’t possible, I’m open to other evidence – video, discussions from other trainers who have co-trained with you, etc. However, if  we don’t co-train my endorsement will be weaker. NB: Even if we don’t co-train we will still collaborate on producing a module.

Tips and other notes

My goal is not to make money from this relationship. Outside of conferences I try to avoid extra travel as it keeps me away from my family. As a result I’m unlikely to be able to fly to your location to co-train with you. I would prefer you meet me for one of my courses.

Given the time involved in mentoring, collaborating and helping to prepare, I can only afford to work with a few people a year. If I say ‘no’ to you I may not be saying you’re not ready; I may simply be saying I don’t have the capacity. Today I have one candidate I have just endorsed, another in the middle of the pipeline and third who will be starting the journey soon. I might only be able to help a couple more people this year.

I have no problem endorsing a competitor – in fact, at least one competitor has an outstanding offer from me – if they apply I will endorse them. The Scrum Alliance needs great people; being in competition with me just doesn’t matter.

Your endorsement request shouldn’t be the first time I see your name. I participate in over 20 mailing lists, many LinkedIn groups and attend at least one conference outside my region (Ottawa/Montreal/Toronto) a year. If haven’t heard your name before, that speaks volumes.

If we haven’t met before, perhaps because all of your community work has been at the local level, then find someone we have in common to make an introduction. The person making the introduction should address the how you fit the vision of being a Scrum Trainer.

If you can’t manage an introduction I’m still open to hearing from you. However, you need to work to establish the bonds of trust and you need to appreciate the time involved. Due to my WIP limits this category is most likely to get an early ‘no’.

Paper and Electronics materials – Paper is an excellent way to establish your initial credibility; electronic training materials give me some sense of your style but they’re just conversation starters. This is a game of “Individuals and Interactions over Processes and Tools”. Eventually I or someone I trust needs to see you in action as a Trainer/Facilitator.

Finally, I strongly recommend contacting only a few trainers at a time and building relationships with them. Sending emails to 140-150 people at a time will likely attract the wrong sort of attention.

Caveat these are my personal guidelines, I’m sure each trainer will have different ones. In addition my guidelines are independant of Scrum Alliance.

Image Credit: robinsonma http://www.sxc.hu/photo/917101

The team has just completed Sprint Planning, committing to four stories:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
  • A review has text and isn’t empty
  • A review has an author name
  • A review has a title
  • At most a review is 2500 characters long

• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
  • Rating from 0 to 5
  • No ½ stars
  • Rating appears at the top of the review

• As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
  • The word “Staff” appears in bold before the reviewer’s name
  • All reviews posted from computers inside the Smallestonlinebookstore offices will be considered staff reviews (This avoids having to tag users as having different roles for now).

• As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
  • …

Right after Sprint Planning Kirby decides he wants to take: “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He invited Brad and Tonia to sit down with him and create some examples that illustrated the acceptance criteria to make sure they were completely fleshed out:

• A review has text and isn’t empty
• At most a review is 2500 characters long
• A review has an author name:
  • “Mark Levison” – valid
  • “mlevison” – invalid –  not a proper name
  • “Levison” – invalid – we need at least two names
  • “C. J.” – invalid – initials alone aren’t enough
  • “John C. King” – valid
  • “J C King” – valid
  • “J. C. King” – valid
  • A review has a title

After 30 minutes they think they’ve fleshed out most of the edge cases, and Kirby invites Brad to pair with him as they start writing the first tests. Brad is skeptical, saying, “I’m a BA – how can I contribute while you write code?” Kirby persists, saying, “Let’s just try it for an hour.” Kirby makes a real effort to name the tests to describe the behavior he’s looking to build.

Sample Tests (Java pseudo code):

@Test public void simpleTwoPartName() {…} // Mark Levison
@Test public void oneNameAreNotEnough() {…}  // Levison
@Test public void initialsAloneAreNotEnough() {…} // J. C.
@Test public void initialsAndLastName() {…} // J. C. King


While he’s struggling to read the implementation code for now, Brad discovers it’s very easy to read the test code. In addition, his questions help Kirby to better name the domain objects because they’re forced to make sense to a non-technical person.

Kirby checks in as soon as the first part of the review system is completed – in this case just the business logic to process and store a review. That happens before reviews can be entered via the GUI, let alone be displayed with books.

The next day Kirby pairs with Ian as well and drives out the GUI for the story. However, they’re having a lot of trouble with trying to spot the difference between real names and user ID’s, i.e. “Mark Levison” vs. mlevison. Rather than get hung up, he shows Tonia (the world’s best Tester) what he’s got working so far and asks her to give that a test. While she is open to the idea, she’s still dealing with testing Stories that weren’t tested in the last Sprint. So Kirby asks Martin (Database guru) if he can pitch in. Martin protests that he has no testing experience. Kirby explains that a rough and ready test by another person is better than waiting. He points out that Tonia will still test the Story; he just wants early feedback. Martin downloads the application from the CI server and fires it up. He remembers hearing about buffer overflow attacks. He tries pasting in over 10,000 characters of text into the review text box. The app crashes. For his next act he tries pasting in all the Unicode Symbols into the review text box. Another crash. He shows Kirby, who laughs and then duplicates the tests and subsequent failures on his own machine. Before trying to solve the two problems Kirby writes two failing Unit Tests. Now he sets about solving the problems. Within half an hour he’s fixed both problems.

Analysis

This time the team is doing better than it has in the past without anyone’s help. Here’s what I see going well:

• Working with a minimum of three people to ensure that the acceptance criteria are well understood.
• Team members pairing to do the work.
• Brad, the Business Analyst, being open to pairing to write test drive code.
• Martin being open to trying Exploratory Testing.
• When testing, Martin didn’t rely on the code from his machine. By testing with a build from the CI server he ensured that he was testing Kirby’s work, and not his own code.

What seems odd:

• Tonia is testing Stories from the previous Sprint and yet the team has claimed they’re complete.
• Stories are being written to enter reviews before the reviews can be displayed with a book. That seems odd. It would be better to display the book reviews first. After all, we can add reviews to the system in any number of ways; directly in the database, through an API, etc. These options don’t require a GUI. However the reviews are useless if we can’t show them to the customer.

What do you find odd? What do you take away from the team’s experience this week?

The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
• As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
• As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
• As a staff member I would like to write a book review so that I can help customers choose great books.
• As a staff member I would like to rate a book I’ve reviewed so I can give customers a quick guide.

We’re in better shape than we have been with previous Sprint Planning meetings but the team lacks concrete acceptance criteria.

Analysis

During the first half of a Planning meeting the team is trying to determine its goal for the Sprint. Specifically, it’s trying to answer the question, “What stories can we commit to?”  To have a realistic commitment the team needs small Stories and a clear understanding of what they will look like when they’re done.

Story

Brad reads the first Story aloud, “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He sees an entire new web page, separate styling and a whole lot of infrastructure to support it. Doug, on the other hand, sees a small addition to each book page. He says that no new style sheets need to be developed. After a few more minutes of debate Product Owner Sue intervenes by saying that reviews will just live on the main page for now. In addition, each review must be under a thousand words and in plain text only.

Debate continues around each successive Story until two hours have passed; and the team is still unsure what they can commit to. ScrumMaster John has been doing his best to bring team members back to focus, but it’s been a struggle.

Analysis

The team is struggling because they don’t have clear acceptance criteria. As a result, they don’t agree on the size and can’t agree on what to commit to. They’re spending the Planning meeting focusing on the question of, “What are we trying to do?” as opposed to, “What should we be doing?”

Acceptance Criteria (from a forthcoming Agile Atlas article):

The goals of Acceptance Criteria are:

• To clarify what the team should build (in code and automated tests) before they start work.
• To ensure everyone has a common understanding of the problem.
• To help the team members know when the Story is complete.
• To help verify the Story via automated tests.

Creating good acceptance criteria is a collaborative effort. Usually, they’re created by the Product Owner working with several other team members. When created in isolation they fail to meet the first two values.

In addition when we create them a few days before the Sprint Planning meeting, team members have time to consider just what they mean, how they fit the product and what is missing.

Let’s wind the clock back for the team to three days before our Sprint Planning meeting.

Story

Sue asks Ian, Brad and Tonia to come spend half an hour with her. Their goal is to hammer out the acceptance criteria for each Story that might be committed for the next Sprint.

At the end of their white-boarding session they’ve got very rough sketches for the first three Stories that clearly limit their scope. In addition there are also textual criteria:

• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
  • Rating from 0 to 5
  • No ½ stars
  • It appears at the top of the review

• As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
  • The word “Staff” appears in bold before the reviewer’s name.
  • All reviews posted from computers inside the Smallestonlinebookstore offices will be considered as staff reviews. (This avoids having to tag users as having different roles for now).

A few days later during the Sprint Planning meeting the team spends far less time debating and manages to get to commit to their Stories within the first hour vs. their traditional two or more hours.

—-
When do you write your Acceptance Criteria?

When helping people learn Planning Poker I always ask what will happen if one person plays/says their estimate before anyone else. Many people usually spot the problem and they call it “influence.” And they’re right. Sometimes a wise person says, “but I won’t be influenced”. The science of ”anchoring“ is well known but until recently I couldn’t think of a personal example that illustrates the problem. Happily a recent trip to San Francisco solved that problem.

I was shopping for a new pair of pants. My expected price was $75 for a decent pair of khaki’s. My first stop was Hugo Boss which sold very casual khaki’s for $150. I thought, “No way! Far too much money.”  In the next few stores I saw several more pairs of pants at $100-120. But fifteen minutes after I first saw the $150 pants, I bought pair for $100 in Bloomingdales (10% discount because I’m a Canadian). I was happy to get such a bargain. After an insanely long walk back to my hotel I realized what had just happened. Seeing the $150 pants reset my price point and now I thought that was the high end and that $100 was “reasonable”. Luckily I didn’t buy two pairs, which was my original intent.

Anchoring is subtle and is it can be pernicious. One comment that really stuck with me in this area came from Dan Airely- even with everything he knows about these kinds of biases and errors he still makes these mistakes.

That is why Planning Poker estimates are done blind, no pre-conversations about the estimate.

Last year I created a short session – Learning Scrum Through Games – to help people explore the basics of Scrum in a one hour format. This year I rewrote it and took it to both Agile Tour Toronto and Ottawa.

We learned a number of interesting things from both sessions:

• Even with a poor quality Product Backlog (the Backlog I gave attendees has many issues) the team was still able to create a pretty good product.
• I don’t give the best instructions to start the exercise and yet attendees manage to create some great comics. When a real Scrum team start it’s chaotic at first. I would prefer attendees get a sense of this during the exercise so I give deliberately vague instructions.
• Ask the Product Owner Questions – in Ottawa only one team did this. As a result many teams were surprised when it turned out that a nine-page comic book was the only thing I accepted as complete
• Done or not Done – Incomplete Comics lead to a good dicussion there is no such thing as 80% done in Scrum. Working software (or comics in this case) is the only measure of progress. This topic led to a brief conversation around the importance of shippable product after every Sprint.
• Many teams jumped around the Product Backlog: choosing whichever stories they felt they could complete. They didn’t ask the Product Owner if it was OK to implement items out of order. Some teams went even further by implementing things the Product Owner didn’t ask for. Quick reminder: if the team wants to do things in a different order or do new things, they have to ask the Product Owner first.
• In Toronto several attendees remarked that it was difficult to understand what was going to happen next. In Ottawa I created an Index Card – Scrum Task wall.
• Timings – the timings in the one handout didn’t work out as well as I’d hoped. It’s not realistic to run two sprints in one hour. If you’re trying to run this yourself I recommend one and a half to two hours which will allow enough time for two Sprints and a good debrief.

Finally, when running this goal isn’t a perfectly run exercise or perfect comic book; its aim is to have people experience the chaos that is Scrum and see how it can work.

Handouts

Intro to Scrum with Games Backlog and Schedule (pdf)
Introduction to Scrum Concepts (pdf)

Slides

Caveat – the slides were just indeed as a backdrop and not stand on their own.