If you’ve any experience in agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example design or user centered documentation.

Many agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:

  1. Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
  2. They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.

In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance.  One of the reasons for this seems to be our view of documentation as being the sole “repository” for product and team knowledge. While that’s true, I also like to remind agile teams that there is another viable form or place for that knowledge – which is the teams’ memory. Since many of the agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.

This article intends to explore that notion just a bit more deeply.

The Teams Collective Memory

I think the intent of agile documentation in general is to only write what has value for the team towards creating valuable software. There is the realization that all documentation has two purposes, either it:

  1. Serves as a communication device as the team is building an architecture, feature, or capability; or
  2. It serves to document something for future consideration.

If we’re worrying about our current sprint or the next few sprints, then conversations are equally important to writing things down. And by this I mean whole-team conversations.

In one recent article I disagreed with a fellow coach who was leveraging a backlog refinement technique that only included Product Owners and a sub-set of their teams. The rationale was driven mostly from an at-scale, Enterprise level perspective. But my key argument against it was that the team would be missing the future context that ongoing discussion, engagement, and story distilling would give them.

Not only from the short term point of view, but more importantly from a longer-term perspective. It helps the team to think about, design for, and anticipate their future. It’s also quite motivating…to know where you’re going.

Patterns of the Collective Memory

An important part of the collective memory is learning from our history. In Extreme Programming there is a term called Yesterday’s Weather. Initially, yesterday’s weather reflected estimates and actual, so the point was to consider past work (estimates, actuals, interruptions, complexity, etc.) when estimating future work.

But I believe the concept is broader than that. Everything an agile team does in its journey is fodder for yesterday’s weather. For example:

  • Similar stories – we’ve done something like this before. In fact, there are 8 stories in the backlog that look very similar to that historical story and this one. Should we handle them the same? What about at the same time?
  • Gotcha’s – last time we did something like that, it really didn’t work out very well. In fact, it literally “blew up” in our faces. Let’s not do that again…or let’s approach it a different way.
  • Knowing over doing - you know, you were right the last time when you said we needed to spike that story. Is this one similar? And would a little prototyping increase our knowledge over simply guessing?
  • Help with just enough – we encountered a story very similar to this a few sprints ago. It helped us a lot to define business rules for the discounts. Is this similar to that? Do we need that information before we can accurately estimate it?
  • Similar, but – oh, this is like that other story BUT only 50% of the testing effort and the development is about 2x more work. How many points did we assign to it before? And how long did it actually take?

I find that the more we bring our ever-increasing collective memory to bear in our user story conversations, 3-Amigo discussions, and backlog refinement, the better the results. Not only results from a delivery point of view, but also from a solution integrity and impact perspective.

Reference Stories

Another part of your collective memory is forming what I usually call reference stories. These are user stories that you use as examples to help your estimation. Whether you’re using Fibonacci-style, T-shirt style, or no-estimate style estimation or something else, having a historical view to stories of different sizes (examples) can really help your estimation and planning.

In this case, reference stories can be:

  • Actual stories where the estimate turned out to align well with the actual (results).
  • Sometimes it’s helpful to have reference stories for the “types” of work you do: front-end, back-end, Devops, UX, whatever.
  • You’ll need reference stories that align with your estimation values. For example, find a nice “medium” front-end story and use that as a comparison for other mediums

I also talk about recalibration of your reference stories. If for example, you find that your size Fibonacci-8 stories typically turn out to be Fibonacci-13’s or 3’s, then you may want to “recalibrate” your Fibonacci-8 story in some way. But be careful not to recalibrate too often – as it impacts the validity of your teams’ velocity going forward.

The Power of Personas

At the core of the user story is the “As a role or person or persona” clause that opens up the story. I often call it a “mini-persona” in that it is trying to connect the teams thinking to the description of a real person, rather than some sort of generic user abstraction.

I’ve found that the more we can describe the role, the better the implementations become. But not only the implementation details, but the entire process we use for developing the story. In particular, the questions and the conversations amongst the team members become much richer.

Because of this, I often try to strongly influence agile teams to develop client or customer personas as a means of supplementing their collective memory. In simple terms, I want to teams to from “As a User” thinking to “As a Persona” thinking. This related article speaks to making that transition.

A final point is to view your personas as emergent and active understandings of your users. That is, you should be actively modifying, extending, and embellishing your personas as you gain ongoing insights. In this way, they augment your collective memory.

Note taking / Scribe

And one final point in establishing your collective memory is something that pre-dates agile. What you might ask? Note-taking. I find that many agile teams forget to take notes as part of their work. For example, backlog refinement meetings are a wonderful place to jot down critical notes that capture the discussions, options, agreements, and flow of work.

As a ScrumMaster, I usually ask for a team member to volunteer to be the “scribe” in each meeting – usually rotating the role. The scribe tries to capture the discussions in whatever tool the team is using to maintain their stories and backlog.

Before the team moves on from the story, the scribe reviews what they heard and the notes they’ve captured. Of particular interest to me is “next steps” in the maturation of the story. If they’ve missed something important, they’ll add it to the stories context before moving on.

Often when I discuss this approach, someone accuses me of “not being Agile”; that I’m forcing the team to write too much documentation. My usual reply is that this is FOR the team and intended to supplement their collective memory as an aspect to their agile documentation efforts.

Wrapping Up

I guess it all boils down to my expectation that each mature agile or Scrum team continuously develops their collective memory surrounding documentation, agreements, experiments, user stories, plans, virtually everything. That it’s a viable approach to augment how much “writing” they do day-to-day.

It’s also a compelling argument for keeping your teams together as long as possible. Clearly your collective memory is also related to the team’s cohesion and longevity.

I hope this article has piqued your thinking about agile documentation – both the written and the remembered kind. Now if I could just remember how I wanted to end this…

Stay agile my friends,

Bob.

 

Comment