Posted on Fri, Mar 23, 2012
by Dhaval Panchal
This is a simple technique with a marketing twist to its name. This title came to me while coaching a team that was struggling to behave cross-functionally and were paralyzed at delivering working software at the end of their sprint. It is a simple mental discipline that I have often used in crafting good user stories and I wanted them to walk their user stories with me.
Everyone is not an expert at analyzing business requirements against technical complexity, but most have had practice walking a dog. So lets ‘walk the dog’, plus this is much cooler than ‘lets walk the user stories’.
Metaphors only go thus far, but a cool title goes much farther. For me, a fancy title, acts as a trigger that allows me to break from the ongoing chain of discussions and engage in an exploratory exercise.
I have used this technique a few times to address primarily two types of challenges -- here are these stories:
Stories ‘not-done’ at the end of sprint
This team was formed of team members that were experts at their part of the code. This was their second sprint as a team and they were struggling to cross-train. To their product owner’s credit, he was creating user stories that were truly vertical slices of functionality that represented end-to-end implementation of features. Their main challenge was that in their two week sprints they were unable to meet ‘definiton of done’ (fully integrated and tested) on these user stories.
In response the team was asking the product owner to further split these user stories in two to three horizontal slices that could be integrated in later sprints. The product owner, was rightly pushing back since that would mean that none of his features would be developed end-to-end in a sprint. As their coach, while I was supportive of the Product Owner’s judgement, I was not sure whether I truly understood the team’s problem. I wanted to try an exercise of discovery with the group, and was concerned whether the group would allow for space and time to go with it.
So I christened ‘walk the dog’ technique. “Sounds like its time to walk the dog,” I said. ‘Sounds cool,’ said some one in the group, others looked perplexed, and afew others perked up.
So I asked the team to bring all their user stories from the current sprint. Starting with the first one, I asked them to walk me through the changes in code base that they will have to make in order to implement this story. I clarified that changes were considered only at the component level and not at the individual class file level. Then we picked another user story and did the same for that user story. At the end when we were done with all the user stories in the sprint, the picture looked like this.
We all stood back and after a few private moments of reflection, one of the teammembers asked why we are modifying on so many components in the same sprint? – bingo!
After this short diagraming exercise where the team literally walked each user story (the dog) through the changes in our components, the team was able to realize that the problem was not with the way user stories were split, but it was the lack of focus created by too many moving parts. The team was then able to rationalize why they were still trapped in their silos and why they were facing so many integration problems.
Earlier the team was asking the PO to split user stories along components so that they could manage complexity within their sprint. This exercise revealed another approach for the team. By limiting technical diversity for their in-sprint user stories, the team was able to reduce complexity within their sprint and also deliver vertical slices of valuable functionality for their product owner.
Vertical Slices of functionality Not in my world!
Another context where ‘Walk the dog’ was useful to me as a facilitation technique was when a team was locked into splitting stories horizontally across components.
Their architectural component environment was tremendously complex. Because of NDA’s with this client, I cannot reproduce their high level architectural diagram, but imagine a bunch of boxes interacting with each other. Some thing like this:
Their working context was further complicated. The team members were doing scrum and working on components A1, A2, and B. Other components' X’s and Y’s were already developed by other projects. This is not to say that changes were not expected on component’s X and Y’s.
So we played ‘walk the dog’. This time however, I presented this technique as a game.
The Game:
Imagine that you have a pet dog and you are new in town. You take your dog to a park for a walk. You have never walked through this park but you have seen pictures and have seen the layout at the entrance to this park. Your objective is to enjoy your stroll through the park and get home before it gets dark.
The Park:
The actual diagram was printed and pasted next to a white board. Next we drew all the boxes (components) on the whiteboard and I purposely asked them not to draw connecting lines between the components. So the diagram on the white board looked like this:
The Dog:
Next we talked about end user functionality and picked a few functional cases.
The Walk:
We picked one end user functionality and charted its walk through all the components that would be affected.
Getting home before dark:
I then asked the team to do a quick round of planning-poker-style estimation to decide whether this end-user functionality can be completed within one sprint.
In the case of our first end-user functionality, the team quickly came to consensus that the end user functionality could not be delivered in one sprint.
We talked about why it is not possible to develop this slice of functionality. Over some conversation, it transpired that no one in the team was confident that services exposed by component X2 will work. They said that although their platform teams have developed functionality that ‘should’ work for them, their prior experience with that group has not been good.
I asked ‘what if’ the component X2 worked as expected, would this end-user functionality still be unattainable at the end of a sprint?.
They said there is no issue if the platform works as expected. We will be home with the dog before supper. No worries.
So for this particular end-user functionality, lack of knowledge about exposed services was the issue. Our conversations turned to how we can gain sufficient get-your-hands-dirty type learning. Reintroducing special story types such as research, spike, and tracer bullets helped to stage a spike that will allow them validate functionality in their platform and deliver end user functionality for their sprints.
Same Park, New Dog:
Methodically we walked each end user functionality through the architectural component park. Along the way, we split many stories into thin slices of end to end functionality. This exercise resulted in a product backlog with enough vertically sliced user stories for the next 2-3 sprints. Valued byproduct of this was a list of immediate project risks, action items and shared understanding.
For this team’s case, the issue was not that they were technically unable to deliver vertical slices of functionality -- it was their inability to work through organizational impediments. For them, all external components represented a big department that had to be wrestled with.
Focusing on thin slices of functionality, exposing component uncertainties one at a time and a good walk in the park helped them reveal impediments. Prioritization of vertically sliced user stories by the PO helped the team and ScrumMaster to prioritize their impediments against the product backlog. Products developed in increments of features/functionality as opposed to the ones developed in increments of components allow for early realization of returns on product investment. Many teams resist this path since the overhead of dealing with all organizational impediments all at once often seem unsurmountable. This exercise helps reveal and prioritize these impediments. It takes courage and tenacity on part of the scrum team to then relentlessly pursue resolution of these organizational impediments – one at a time.
Posted on Fri, Sep 09, 2011
by Dhaval Panchal
Most of us have to pay a visit to the scissor man/lady every couple of months. Others who don’t have to or choose not to, I envy you. As a kid, my visits to the barber shop were scary ritual. The thought of someone using scissors, clippers and other sharp pointed tools a few millimeters from my scalp and ears was terrifying. After surviving many close calls with sharp objects, I was fairly certain that the worst that could happen would be a couple of cuts, minor scrapes, and a hideous hair style. Over the years what gave me courage to go to our neighborhood barber shop was our barber’s technique/skill and relaxed friendly conversation that always ensued at his place. (That and my mom and lately my wife :).
I have not completely overcome my fear of visiting barbershops yet. There is always the possibility of getting bruised or a bad haircut. However, I find it reassuring that it is in the nature of my fur to grow back and warrant another shot at presentable appearance. Scrum teams and product owners that appreciate this emergent characteristic of product backlog find themselves engaging in healthy dialogue during backlog grooming sessions. As a coach when I help product owners and teams groom their backlog, I seek to use tools and techniques that foster collaboration, allowing them to acknowledge the emergent nature of product backlog items. I have often found myself playing the role of that friendly neighborhood barber, armed and ready with agile tools to help POs and teams groom their product backlog.
Collection of techniques
- User Story format: (As a [type of user] I want [some goal] so that [some reason])
- Three C’s (Card, Conversation and Confirmation)
- INVEST model
- Special story types – Research, Spike & Tracer bullet
Collection of Tools
- Index cards or sticky pads (lots of them)
- Sticky dots
- Sharpies
- Poker Planning cards
- Whiteboard/Flipcharts
- Scissors
These are some tools and techniques that I find myself applying most frequently. The list above is a basic toolkit. (Good barbers always have a secret stash of innovative experimental contraptions, should the customer feel adventurous 
)
Application of tools and techniques during product backlog grooming is highly contextual and it largely depends on the nature of the backlog prior to the grooming session, comfort level of product owner and team with grooming techniques, and other external factors that indirectly influence the backlog grooming session.
A well functioning agile team grooms its product backlog at least once every sprint to build a professional product that sports stylish curls with hints of highlighting.
Posted on Wed, Mar 16, 2011
by Monica Yap
In my first post in this series, I described a Product Owner anti-pattern known as the Absent Product Owner. Now I’d like to introduce you to another: the Churning Backlog.
What is a Churning Backlog?
During a sprint, the sprint backlog (which is supposed to be locked down) is consistently being changed at the request of the Product Owner — either stories are being added or existing stories are being modified to the extent that the team needs to re-plan and a large amount of re-tasking must take place. This can be caused by any of the common root causes listed below. When this happens, the team cannot stay focused because what they are working on keeps changing, a lot of waste is produced (unfinished code is waste), and the team will not be productive.
Common Root Causes:
- There is not enough planning done at a higher level, i.e. no Release Plan or Product Roadmap.
- There is no adequate pre-planning done in between sprints; this is also called backlog grooming or a look-ahead.
- There is no adequate planning done with the appropriate stakeholders, so there are ‘surprise’ requests coming from the unexpected stakeholders. This also ties in with another anti-pattern called Not Enough Stakeholders, which I’ll cover in a future post.
- The Product Owner is not fully aligned with the product release, vision, or strategy, therefore the backlog must be adjusted.
Smells:
- The sprint backlog is always changing during the iteration. This can be detected through analyzing the sprint burndown charts.
- The Product Owner and stakeholders rationalize small changes. “This is just a clarification, it shouldn’t impact the sprint.” “This is the same size as X, so pull X out and do this instead.”
- The Product Owner and team continually have to split stories to get something done during the sprint.
Remedies:
- Pre-planning with the Product Owner before each sprint planning session, and identifying concrete acceptance criteria for each story. The ScrumMaster should be able to help to ensure that this happens.
Personal experience: When I was a ScrumMaster, I set up reoccurring meetings with my Product Owner to groom the backlog a week before sprint planning — this helped to identify questions (or gaps) the PO would need to clarify to get answers. Then I scheduled another follow-up meeting with the PO and the team to preview the stories at the top of the backlog to get a high-level estimate and draw out more questions that needed to be addressed during sprint planning.
- Help the Product Owner to establish a group of stakeholders as the Product Definition Team, and set up a backlog brainstorming and prioritization session regularly (the interval depends on the product and context).
Personal experience: A Product Owner I worked with had stakeholders scattered in different cities. He flew them into the home office every quarter, and they worked together to conduct release planning, roadmap updates, backlog brainstorming, story writing, and prioritization. This allowed those stakeholders to provide their input and enabled the PO to understand their priorities — the group worked together to calibrate their priorities, so all stakeholders had buy-in and supported the release plan.
- Help the Product Owner and business community commit to a vision statement, a roadmap, then a release plan
Posted on Fri, Feb 25, 2011
by Paul Dupuy
How Long Does It Have to Be?
User Stories are often used for backlog items by Scrum teams. Unfortunately, one of the most important aspects of a Story — its extremely short length — has been subtly transformed over time and Stories have lost their original essence and potency.
Story writing is commonly taught as a kind of template: “As a <type of user> I want <some goal> so that <some reason>.” The writer is then encouraged to immediately document acceptance criteria in the form of a constraint list. It is considered “poor form” to create a Story that someone outside the team (say, a Senior Manager stakeholder) can’t understand from its documentation alone. This User Story Template format was popularized by Mike Cohn in his book User Stories Applied and it is quite different than the form used in the original technique.
I’ll make the case here that an ideal Story’s documentation should be nothing more than a short, memory jarring name — what Robert Martin calls a “mnemonic token” [1].
The Storied Past
User Stories were first described in 1995 by Ward Cunningham in his “EPISODES” pattern language. The pattern is named Implied Requirements:
Development commitments generally obligate developers to meet some customer need in a timely and satisfactory way. The tension here is to define a need in sufficient detail that commitments have meaning without exhausting up-front analysis or over constraining a solution. Therefore: Select and name chunks of functionality. Use names that would have meaning to customers and be consistent with the product initiative. Allow these names to imply customer requirements without actually enumerating requirements in the traditional sense. [2]
Examples like “High-quality printing” and “Settlement date positions” are given. In the related Work Queue (Backlog) pattern, it’s made clear that there is nothing more than implication in an Implied Requirement: they are “really just names” and the “deliverables may be ill-defined, being represented more by a vision or desire than anything concrete or measurable” [3].
The term “Implied Requirement” is scarcely used now, with a few exceptions such as Jim Coplien and Neil Harrison’s Organizational Patterns of Agile Software Development, where Cunningham’s pattern is reproduced [4]. “User Story” is the name the industry has adopted for the revised Implied Requirements pattern. But before the now familiar predicate was applied, when the concept first began garnering attention by virtue of inclusion in the Extreme Programming corpus, it was known simply as a “story”.
Tell Me a Story
The term “story” first surfaced in 1999 with Kent Beck’s Extreme Programming Explained; it is defined in the Glossary as “one thing the customer wants the system to do” [5]. In the Planning Strategy chapter, it is explained that a story is written on an index card “with a name and a short paragraph describing the purpose of the story” [6].
The amount of story documentation described in XP Explained exceeds the “just name” length given in the Implied Requirement pattern. However, in the Planning XP book released the following year, Beck’s story length is reduced and falls back into alignment with the minimal approach. He also begins to use the now familiar term “user story”.
Are You Gonna Use That?
“Simplicity is the
ultimate sophistication”
– Leonardo da Vinci |
In Planning Extreme Programming, Beck and Martin Fowler return to the “conceptual” definition of the newly named User Story, explaining that details are elaborated when you build the stories, not when they are written:
“The shorter the story the better. The story represents a concept and is not a detailed specification. A user story is nothing more than an agreement that the customer and developers will talk together about a feature. Hideous written detail is not necessary if the customer can work with the programmers while they are programming. … It’s not that you don’t need all of those details. You just don’t need them all up front. When you need to build the stories, then you need more details. But whatever you do to make the story more detailed, do it when you need the details. [7]
Mike Cohn echoes this sentiment at the beginning of User Stories Applied: “Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details. That is, have a conversation about the details at the point when the details become important” [8]. Had he promoted this approach instead of User Story Template, the book would have been much shorter.
When teams defer documenting the details, they reduce the potential for waste and thereby reduce the cost to build software. If the priority of a Story is decreased to the point that it is never built, the effort spent creating and maintaining the Story artifact is considered waste. As David Anderson makes clear in his dense and thorough Agile Management: “in order to maximize the Production Rate, waste from changes must be minimized.” [9]
Haven’t You Got Something Better to Do?
Another consequence of minimally documented Stories is time saved that would otherwise be spent writing. It takes time and effort to write “just” a paragraph of description and “just” a list of acceptance criteria for each Story. The Product Owner has plenty of other work to do — market research, customer collaboration, competitive analysis, product feature innovation, release planning, acceptance testing, manager meetings, etc. — is documenting a Story really the best use of valuable time?
Furthermore, there is a kind of cognitive burden entailed by excessive documentation: the writer feels disinclined to “waste” the effort already spent documenting a Story by rewriting it or reprioritizing it in response to changing needs:
The User Story practice enables flexibility because a small fraction of time is originally invested to create user stories for the backlog. The team is then free to reprioritize them in response to new information or changes in the environment without wasting much work-in-progress. … Consequently, the product utility is improved, and the cost to build the software is reduced. [10]
Accentuate the Evocative
With such a small amount of documentation — just a name — how will folks come to know the Story details? The minimalist Story acts as what Amr Elssamadisy calls an evocative document: it “evokes the memories, conversations, and situations of those who wrote the document” [11]. A team using the Evocative Document pattern
spends more time in face-to-face conversation and less time building and maintaining documents. The documents they keep tend to be simple and only comprehensible to those in the conversation; therefore, to transfer the knowledge behind the document to someone who was not there, the conversation and context have to be repeated and the document built from scratch. What is gained by this is a much better transfer of knowledge within context that ultimately leads to more proper understanding of the application and reduced maintenance costs.” [12]
The lack of detail in a minimalist Story acts as a forcing function that fosters Agility through increased communication: “To encourage conversations, write down just enough information to remind you and others what the subject is. For those who have not participated in a conversation on the topic, the text will not have much value and will thus prompt them to find the right person to talk to” [13].
Now Why Didn’t I Think of That?
Because the Product Owner does not commit to written detail in a Story artifact, the team is free to creatively develop the feature with fewer preconceived constraints. Innovation is intrinsically encouraged. The lack of explicit specification creates a vacuum that must be filled by the entire team: it fosters a team-wide synergy that results in a realization of the feature which is richer and more creative.
The short short Story takes a “just-in-time commitment” approach. Mary Poppendieck explains the value of this in Implementing Lean Software: “As we guide our product development process, we need to recognize that developing a product is all about learning, and the longer we defer decisions, the more we can learn” [14].
A Principled Stand
The ability to perform real-time adjustments in response to change requires an “infrastructure” that facilitates continuous refactoring as features are elaborated and modified. There are engineering patterns that Agile teams typically use to ensure the software being developed is sufficiently malleable and stable to withstand continuous change, such as Test Driven Development, Refactoring, Automated Acceptance Testing, and Continuous Integration. Social patterns like Pairing, Whole Team Together, and Collective Code Ownership help create an environment that spreads knowledge of the Product across the entire team, fostering the synergy, creativity, and courage necessary to shape the software dynamically.
In and of themselves, short and sweet Stories directly align with, support, and encourage many of the Agile Manifesto Principles:
- Simplify
- Self-Organize
- Trust and Enable
- Collaborate Daily
- Face-to-Face Conversation
- Welcome Changing Requirements
Testing, Testing, 1… 2… 3…
So, if a Story does not contain documented details prior to working on it, and evocative documentation is sufficient to engender a shared understanding among team members, do we ever need to record the specific details of a Story in persistent form? Yes: when work begins on a Story, the details are recorded in the form of automated acceptance tests.
The Automated Acceptance Test pattern is a safety net that ensures the loose conversational specification “setup time” is not wasted — at the appropriate time, the details are committed to automated tests which are objectively verifiable and capture the requirements as executable specifications. The tests act as regression protection, persisting a team’s memory of the story details in a “permanently accurate” form (if the tests are executed regularly). A good automated acceptance test framework encodes the specifications in Domain-specific Language so anyone familiar with the business domain can read and write them.
The Long and The Short of It
An ideal Story is very short:
- Just a name
- An evocative document
- Creatively elaborated when work begins
- Detailed as automated acceptance tests
Notes:
- Robert Martin and Micah Martin, Agile Principles, Patterns, and Practices in C# (Englewood Cliffs: Prentice Hall, 2007) ,14.
- Ward Cunningham, “EPISODES: A Pattern Language of Competitive Development”, in Pattern Languages of Program Design 2, ed. Vlissides, Coplien, Kerth (Reading, MA: Addison-Wesley, 1995), 375-6.
- ibid., 377.
- James Coplien and Neil Harrison, Organizational Patterns of Agile Software Development (Upper Saddle River: Pearson Prentice Hall, 2005).
- Kent Beck, Extreme Programming Explained: Embrace Change (Boston: Addison-Wesley, 1999), 179.
- ibid., 90.
- Kent Beck and Martin Fowler, Planning Extreme Programming (Boston: Addison-Wesley, 2001), 46-7.
- Mike Cohn, User Stories Applied: For Agile Software Development (Boston: Addison-Wesley, 2004), 6-7.
- David Anderson, Agile Management For Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River: Prentice Hall Professional Technical Reference, 2004), 101.
- Elssamadisy, Agile Adoption Patterns (Reading: Addison-Wesley Professional, 2008), 149.
- ibid., 143.
- ibid., 145.
- ibid., 151.
- Mary Poppendieck and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash (Boston: Addison-Wesley, 2007).