Traditional requirements approaches don’t work, but user stories are not enough.

So, what does work? Testable examples (i.e. ATDD and BDD) aka Specification By Example. Testable examples, sometimes called executable specifications, provide a lightweight, objective description of a need. They serve as a common language across roles, from business to the development team, allowing us to understand and improve our business rules. As an added benefit they can even be used to automate acceptance level testing.

So, don’t gamble on your requirements, review this introductory primer on ATDD and BDD.

I had the privilege of co-presenting this introductory with David Bulkin session in Las Vegas at the recent Scrum Gathering.

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?”
…
Read More…

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”. Read More…

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. Read More…

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

Read More…

The recent Backlog Refinement session helped split the upcoming User Stories.

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. Read More…

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.

John Miller recently challenged some of us to summarize agile for the K-12 crowd. I wound writing a tweet I could share with my nine yr old:

“Focus on the customer. Build amazing quality stuff. Release frequently. Always improving. Two heads are better than one”

MJ and George both take issue with “Always Improving” – MJ because it implies that your always going up/improving. George feels that it doesn’t imply continuous learning.

What would you write for the K-12 crowd? Have fun with it.