Hot Needle of Inquiry

On the leandevelopment list, there has been a bit of a discussion on how long the “backlog” should be, and why. This was triggered in part by a posting from Mary Poppendieck, in which she said:

It doesn’t matter who owns the backlog, the responsiveness of the development team to real needs of customers will be in direct proportion to the length of the backlog.  This is a supply chain issue, and in general, the shorter the supply chain, the faster its response. (more…)

For some reason, I’m remembering a guy in Florida who pushed his team to commit to more and more. I asked him why after the meeting. He said “People need stretch goals.”

Now a little pressure helps me get things done, I freely grant that. But it only works if I get them done: otherwise the pressure just frustrates me, makes me feel bad, makes me slower still.

For the business, the value of Agile is that you know where you are and that gives you a good idea of where you will be. If you’re working on stretch goals, you don’t know where you will be, you have some under-pressure wish-driven fantasy picture of where you will be. All you know for sure is that you won’t be that far along. You have doomed yourself to disappointment.

As managers, we need our developers to find their joy in getting things done. We will not prosper if they get off on the joy of heroic effort, or the joy of slamming in last-minute fixes that will save the project if only they are successful. 

People under pressure take shortcuts. In software development, shortcuts show up when poorly crafted code slows us down and piles bugs upon bugs. We don’t need that.

We need to know that when something is reported done, it is actually done, working, complete. We need to know that it won’t have to be revisited, taking up an unknown amount of time in the future.

Pressure makes that impossible. Pressure robs us of what we need.

To get what we need, to get things done in a predictable fashion, to get things done well, we cannot tolerate stretch goals. We need to value commitment to a result that can be attained. Stay away from stretch goals, that’s my advice.

Here’s a little something I wrote to the Scrum list, to the 14,321st team who are having trouble using tasks in Scrum planning. This team was having trouble getting through the planning in under 2.5 days. (!)

Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put it back together, which is always difficult. I’m writing a Kate chapter about that right now.

What I recommend as a planning process is this:

1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
   (Similar to tasks but we’re not going to do the work, nor track it that way.)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.

Q: But for this to work, everyone would have to be able to work on everything.
A: Yes, that would be ideal. And you could do pair programming — that would fill in needed skills and people would learn as well.

Q: But even so, for this to work, stories would have to be very small.
A: Yes.

Subsequent to the Technical Debt workshop, Chris Sterling posted on the IT Manager’s Dilemma, concluding that they make “rational” decisions to get where they get. Matt Heusser offers some thoughts suggesting that technical people need to make more principled decisions when they estimate and do their work.

I’m not optimistic about people making principled decisions, as a rule. We don’t seem to be wired for it. If our manager is pushing for more features, and the penalty for writing bad code is to get to write more bad code, it is a reasonable response just to go ahead and do it. Anything else will be painful, and we were built to avoid pain.

I don’t work for a living, and do not hope to any time soon. So I don’t know whether, under pressure, I’d be less inclined to write crappy code than I used to be. My guess is that I’d do better than I used to, for two reasons:

1. I’m just better at it. I’m more sensitive to bad things arising, and know more and easier ways to make things clean. So I’m guessing I’d do better just because I’m a bit less messy by habit.
2. I’m more clear in my mind about where my joy comes from: from doing the work as well as I can. So I’m guessing I’d be a little less sensitive to the temptations of the situation.

But I really don’t know. Still, I think that the notions above are just about our only hope when it comes to keeping tech debt down. We need to become better at seeing debt and removing it, and we need to care more about our craft.

We can get help with the first of those. As for caring … I don’t know how to help you with that.

As my old friend Charles Bair used to say, that’s a two-part question. “How?” and “should user stories be written?” The answer to the second question is “No, not really.”

This notion comes up owing to preparation for a panel at Agile 2008, in which I have decided not to participate for personal reasons. But I’d like to share my concerns and thoughts.

What is a User Story?

A User Story is a piece of system functionality, understood by the Customer / Product Owner, representing an increment of business value, to be implemented by the team.

A User Story is not a requirements document. It is not a written communication between requirements giver and requirements implementor. A User Story is just “a thing to do.”

How is a User Story Devised?

Well, in principle a user story can be devised in any old way. The requirements giver “thinks them up”. However, there are valuable principles to consider.

The “As a … I want … so that …” notion reminds us that we need to consider all the users of our product, that we need to consider what they want to accomplish, and that we need to turn that into a feature that they want. These are all good things for a requirements creator to think about … and they are all valuable to communicate to the developers, to aid their understanding.

The “INVEST” notion reminds us that stories should ideally be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. All good notions that should be considered when deciding what to ask for.

So these ideas are very important during the time when we are trying to think of stories. At least some aspects of them are well worth communicating across the whole team.

How is a user story communicated?

I’ve written on this before, in my article on Card, Conversation, Confirmation. The fundamental notion for our purpose here is that a story is communicated to the team by conversation. The communication is not a written document supported by Q&A. It is an explicit conversation between product owner and developers.

The conversation ideally ends with a clear statement of the acceptance criteria for the story, answering the question “How will you know that we have done what you’re asking?” The answer comes, again ideally, in the form of one or more executable tests which, when they work, show that the story is done.

How is a story tracked?

A story goes through a number of state transitions in its lifetime. It starts as a gleam in the eye of the product owner. It becomes something the product owner really wants. It becomes something that the product owner decides to schedule. It gets scheduled into an iteration. It is coded. It is tested. It is finally deemed to be done. Through all these states, we want not to lose the story, and usually we want to know what state it is in, especially as it goes through those final ones. How might this tracking be accomplished?

One really great way is to create a card representing the story, and post it on a wall chart showing the story’s current state. In one of his excellent articles, Jim Shore provides this picture of story cards on a wall:

Story cards on a wall are simple, public, easy to maintain, highly participative, and communicate very clearly. Highly recommended. What should the cards say on them? Anything at all that reminds everyone of what the story means. The card could say “Overtime Pay”, even if the original thinking was “As a manager of hourly-paid employees, I want them to be paid overtime in accord with the law and our policies, so that they will be properly compensated and we will be rightly seen as a just and friendly company.” We discussed all that stuff in the Conversation. We only need to quote enough of that to remind ourselves what we were talking about.

And remember: the card is backed up by an executable test that is quite probably under version control in the software repository.

That said, some teams, rightly or wrongly, want to do more. Perhaps they want to have some kind of database of story definitions, or to communicate stories across time and space. Personally, I’d push back against those notions fairly hard, but there certainly are cases where that’s what you should do.

When you do, however, you have just committed yourself to a different, heavier form of user story. The card is just a token for the story, used to mark its progression through the process. This heavier thing now begins to serve as a permanent archival document, part of some formal representation of the project. It is certainly OK to do this, even if by some standards it is wasteful.

A formally written story is an option!

By Agile standards, turning the story into a document is an option, not a standard and necessary part of doing user stories.If we are going to do it, we should strive to write the minimum amount that will serve the need in hand, which may be nothing more than to tell some remote team members what is going on. For some teams — few teams, I believe — we have additional needs for archival properties, or distance-communication properties, that require us to do more. We should do that … albeit only reluctantly.

Bottom Line

The story is a user-understood bit of requirements that the team is going to implement.

The best way to communicate to the team what is needed is to talk with them. The best way to be sure we have a mutual understanding is to define a test. Some kind of document might be provided as backup or detail on the conversation. That document should not be carrying most of the weight of the story: it is the job of the conversation, and the confirmation, to do that.

The “As a … I want … so that” and “INVEST” notions are quite important during consideration of what stories we need, and may be important during the communication of the story to the team. That doesn’t mean anything should be written down in this format … nor does it mean we can’t write things down that way if we want to. We’re allowed to do that. It’s not required.

Thus we see that a user story is a thing that needs doing, that must be effectively communicated and tested. We see that a user story card or a user story tool entry might be a written sort of thing. But the writing is not the most important part. Quite likely it is the least important part, far behind the thinking, the communicating, and the testing.

… sometimes they’re popular because they’re easy.

1. Sorry, everyone, I just couldn’t resist.
2. Sorry, women, but as I see it it doesn’t cut the other way.

However, in all seriousness, there’s a lot of stuff that you have to do beyond what’s in the Scrum literature if you want to be really successful. I freely grant that a clear understanding of obstacles, and working to remove them, will pretty much get you there. Or you could pick up a book on Extreme Programming …

Test-Driven Development checks intention. Customer Acceptance Tests check desire.

When a programmer uses TDD, she knows what the customer desires. She thinks about what she intends to make the program do next, as a step toward what is desired. She checks that it does not do that, then makes the program do it. She is using TDD to help direct her intention and to check that she has accomplished her intention.

The customer knows what she desires. When she provides acceptance tests and examines the results, she is checking to see whether she has received software that meets her desire.

This may seem like an awfully find distinction and, who knows, in a day or a year I may have or hear a better way to put it. But the customer acceptance tests are about the goal, and the programmer tests are about the path to the goal.

Michael Feathers asks “Are Nested Classes Really a Good Idea”.
I have tried them from time to time, but as with Michael, find that I hardly ever use them.
I wonder: what would make something worth of being a class, but not worthy of existing on its own?