specs pretend to be complete

There’s something about a functional spec that makes it seem complete. Even when it is clearly marked as being a “Draft”, or when it has “TBD” sections; these just feel like minor blips on the way to completeness. A spec — even a badly written one — has an air of authority.

But express exactly the same information as a set of examples, or as a set of rows in Fit tables, and something magical happens. Suddenly that same information is obviously incomplete, demonstrably sporadic. And suddenly it’s easier to imagine how the solution might be developed incrementally, and that some of the examples could have lower priority than others. Change also becomes less of an issue, because a set of examples doesn’t have that air of being a work of art.

Get past the fear of incompleteness and a whole new world of possibilities opens up.

looking back a year

Today being the first of the month, I decided to take a look back at what I was blogging about last February:

A couple of the posts (notably keep the task board visible at all times) seem to have acquired a life of their own in the intervening months. But the post that stands out from this future vantage point is what is “quality”?. Since I wrote that piece I’ve discovered Tom Gilb’s work and studied it in depth. He’s built an entire agile method around the concept of testable qualities – one that I would love to try, even on a toy project. I am beguiled by the notion that requirements and user stories are solutions to quality problems. Nice to see that my thinking is consistent across a period as long as a year!

And how I managed to post on the last day of that particular month is beyond me…

looking for patterns in the churn

One of the projects I work with has very high churn in the backlog. There are repeated and frequent seismic shifts in the project’s priorities, and each time that happens a whole slew of twenty or more cards instantly appears at the top of the pile. And a couple of times the entire backlog has been junked – sorry, archived. Naturally this all has side-effects, some good and some not so good.

It’s important to note that this project is considered a roaring success. The team has achieved amazing things in a short time. And its ability to cope with the backlog churn – while maintaining velocity – is remarkable. And yet the churn is disorienting: the team’s retrospectives regularly discover that individuals feel the project is out of control, or directionless.
Continue reading

the agile requirements story

Yesterday James Shore completed his multi-part guide to agile requirements management, or collaboration as he prefers to call it. These articles are well worth studying and adopting.

I particularly like Jim’s focus on Eric Evans’ UbiquitousLanguage pattern as driving the process. I believe that in our industry’s collective rush to eliminate muda and become extreme many teams have made a huge mistake and thrown the domain model out with the bath-water. Jim shows how the language of the domain can become the key to successful collaboration between developers and stakeholders.

I also like Jim’s over-arching describe-demonstrate-develop process – particularly the comment that the developers shouldn’t run the Fit tests while doing the develop part. As we saw at the dojo in Rotterdam, it can be too easy to fall into the trap of using customer tests for a kind of TDD, at which point coverage and design both go missing.

Jim’s article yesterday now brings all of these pieces – and more – together in a coherent whole.


I spent another enjoyable day at XPday5 yesterday. As always, it was great to meet up with old friends and colleagues, although I never seemed to have the time to get into real conversation with anyone!

I was there to run a new version of the jidoka session, this time including games and a working group. The new format was great fun, and I’ll be running it again at SPA2006 next spring.

My main highlight of the day was Tom Gilb‘s introduction to ‘quantifying any quality.’ This was a compressed introduction to the Evo method’s approach to requirements, in which projects set numeric goals for everything from usability to maintainability to innovation. I was stunned by this approach, and spent some time over lunch quizzing Tom further. Tom’s thesis is that most of what we call “stories” or “requirements” are actually solutions to deeper business and user needs. Tom ferrets out those underlying needs, quantifies them, and then leaves the development team to decide how best to meet them. This chimes well with some of my experiences, so I’ve vowed to study Evo in detail during the next few months.

user story format

Rachel Davies and Brian Marick had a conversation recently that bore some powerful fruit. Discussing the “As a [role], I want [ability], so that [benefit]” style of writing stories, Rachel comments:

“I dropped this story format about 2 years ago because it encourages people to think of story cards as mini requirements documents”

Her subsequent justification is all about people and interactions, and makes a lot of sense to me.

the product owner must pull

Bad things can happen to a project if the Product Owner doesn’t manage the story pile. And consequently bad things can happen to the software development team that is cast adrift in the doldrums.

There are many reasons why a software development team might lose productivity. One that is often overlooked – especially in discussions of extreme programming – is when the Product Owner fails to drive product from the team. Maybe the market research hasn’t been completed. Or maybe the project stakeholders can’t agree. Maybe there is no clear vision. Or maybe this is a research project with a “let’s see what turns out” approach. Whatever the cause, the effect is a Backlog with too few stories in it. Or worse, a Backlog with conflicting stories, and stakeholders who bicker at the iteration review meeting.

Textbooks and training courses tend to give developers the impression that the Backlog just appears, manna from heaven, perfect and always in just the right amounts. No-one told them what to do when that isn’t the case. Most teams will fail to notice the situation for some time, and will fall into destructive behaviour. The developers with a strong technical sense will push for the addition of ‘obvious and essential’ architectural stories to fill the gaps in the Backlog. At the same time those with a domain background will just ‘know’ what is the right direction, and will push for new stories to support their own personal hobby-horses. Those who need strong leadership will fall into despond, and the more vocal of these will cast a cloud over the team room and everyone in it.

If the story pile continues to be under-managed, the team’s worsening morale will inevitably affect productivity. (I attended an iteration review meeting recently in which the developers demonstrated no new features and the Product Owner came to the table with no new stories – and yet everyone knew there was loads to be done and very little time in which to do it! In order to fill the vacuum some of the developers began tabling their pet stories for consideration. Chaos ensued and, unnoticed, morale slipped another notch.)

Look at the problem from a slightly different perspective. All of the agile software development methods share their underlying principles with lean manufacturing. Productivity is based on short cycles and interlocking feedback loops. And the pace of development is set by the arrival rate of kanban – story cards in our case. The whole basis of agile software development relies on the Customer pulling features from the production team. And the rate of pull must be sufficient to drive the cycles and feedback loops. The supply process will disintegrate when there is insufficent demand.

Update, 18 Apr 05
For a ‘theory of constraints’ take on this story see the product owner must pull (revisited).

Turning requirements into user stories

If people don’t “get” user story writing, try this simple exercise: Take a non-functional requirement and convert it into one or more stories by looking for the user(s). Here’s an example from a project I did a few years ago:


The Functional Spec included a non-functional requirement for an overnight batch run to create a particular database report. We looked for the users and discovered that this report was for only one person, who liked to begin each day by looking over yesterday’s figures. So we turned the requirement around and wrote it from that user’s point of view. Now we have a user story concerning this chap’s wish to read that report. It completely replaces the earlier non-functional statement, which was clearly a solution, not a requirement.


User stories also free the developers to be creative in providing a solution, because they are focused only on the business need and not on the analyst’s perception of today’s (or yesterday’s) technical constraints. On the project above it turned out to be easiest to build the report on the fly, incrementing it with every transaction throughout the day. This solution failed to meet the original ‘requirement’, but in fact over-delivered for the user, who was now able to view his figures at any time during the day.

Get in touch if your team would benefit from training in how to avoid this kind of mistake.