Struggling to get into Shu business

Why it's taken me years to explain simple things simply

Shu Ha Ri explains how we learn

I've often found the terms Shu, Ha, and Ri useful to refer to the three stages of learning Alistair Cockburn described in Agile Software Development. I'll usually explain that to learn something we start at the Shu, or "following" level. Here we are focusing on learning a simple set of instructions for a technique and consider a particular learning experience successful if we can follow that set of instructions and realize success.

Later we'll learn that simple techniques have limits, and we'll learn to vary the technique or combine it with other techniques to achieve success - that is in the Ha or breaking away stage.

Finally I explain that many experts find themselves in the Ri stage - or fluency. There they freely improvise, mixing and matching techniques and inventing new techniques - tricks I've heard them called - because these invented techniques are tricks until we can explain them and teach them to others as somewhat repeatable techniques.

So, that's where the complication comes in.

Shu Ha Ri doesn't help us find those simple steps - it only lets us know we need them

I'm lucky enough to have learned quite a few things from a number of experts. I'm serious about that lucky part. Not everyone gets those opportunities to learn first hand as I have, so I consider myself very lucky. As a result of learning techniques from user-centered design experts, specialists in more traditional requirements work, and Agile experts, I've acquired an odd fusion of techniques swimming around in my head. Those, combined with my own unique perspective and experience, have resulted in the tricks that I feel pretty proud of.

Sadly, I have to call many of them tricks, and my tricks in particular, because I struggle to explain them. That is to say, I struggle to arrive at a step-by-step Shu process that I can explain simply, and that people can learn and repeat.

I've heard Alistair explain that once you reach fluency level - or Ri level, you sometimes forget how the simple Shu steps worked. But, for these tricks I'm talking about, there never were any Shu steps - at least I never learned any. Because they're an odd blend of a number of techniques, and a few happy accidents in the context I was working in at the time. I never learned useful language to explain them. And, for the group I was collaborating with at the time, the improvisations seemed obvious. They didn't need explanation either.

But, I'm happy to report some success.

Finding Shu steps that work takes years of trial and error, but eventually it pays off

I write this at 12:45am from the way-too-crowded waiting area in the Bangalore airport. I've just taught a 4 day class to a group of folks here in India - and happily it's felt more successful than any I've taught prior. Nothing feels better than finally getting the language right, coupling that with some simple exercises, and seeing the people in that class really get it. I can see in their words, body language, and movements as they perform the techniques that they've gained more fluency more quickly than others that I've taught.

Actually, as I write this, I wonder if we should all remember that those in India doing IT work are pretty darn smart. If we want to stay competitive in the US, or wherever we live, we'll have to do more than simply "be collocated" with the business.

But, back to my story.

For participants, learning a new technique is a deceptively small thing. An instructor explains something. You listen and it makes sense. You try out a technique in an exercise, and it works. What's the big deal?

But, it's taken me years - really four years now – to figure this out. I'll need to write a public apology later to the people who endured some of my earliest classes starting in 2002. Very rough Shu at that time. I almost obfuscated techniques rather then clarifying them.

This time though, I saw my small class of nine pick up the necessity of understanding and modeling business goals. During exercises they poked each other with the "why stick" - to find the real business goal behind the simplistic "build some software" goal usually expressed in software development. Then, they used the goal-question-metric technique to identify meaningful measurements to detect business success.

Those business goals come in handy. Much of what I do is informed by user-centered design thinking and techniques. But, I've found that if you don't balance user-centricity with business-centricity – or person-who-uses-it with person-who-pays-for-it – you don't succeed in delivering the value you intend to. Well articulated business goals provide goal-alignment for stakeholders and spell out pretty simply to those on a software design and development project where the business value should come from. It seems to help the business people when you can remind them where they believe business value comes from. Software development is tough for everyone involved.

Many in the Agile software development world labor under the false assumption that working delivered software = business value. Actually business value generally comes from using software. Building and delivering it is simply cost until then.

If we know that the best way to get value from software is from using it, then it's a good idea if we start focusing on users and use as soon as possible. I find my head a little thick at times. I finally really grok Larry Constantine and Lucy Lockwood's reason for calling their design approach Usage-Centered Design - because it's the usage (stupid) that earns us the value.

But I digress.

The group I worked with built user models - my neutral way of saying I don't care if it is an actor, user role, profile, or persona - just figure out who's using your software and why. Write it down and leverage it.

We moved through modeling use using user tasks and workflow models. They wrote clever user scenarios, and used them as a foundation to create software user interface using paper prototypes. They leveraged the task workflow model and experience from designing Ui to create an incremental release plan. One that delivers something at each release that users of the application can actually use to meet their goals - which of course is mandatory for business stakeholders to reach their business goals.

Honestly - if I hear "prioritize your user backlog by business value" one more time, I'll scream. It just doesn't work. It's not that simple. Usage needs to be more explicitly taken into account. Although simple prioritization sounds like a set of Shu instructions, it isn't - because the person practicing that approach needs to realize some success. I won't rule out that this approach has been successful for some - but it just doesn't work for me. That Shu just doesn't fit.

I've gotten off topic again. I'll get back to my original rant.

Arriving at Shu instructions for a new technique requires testing

My real point with all this is that identifying, describing, and teaching new techniques is tough. The toughest part, at least for me, has been finding language to explain them. To find that simple language I've had to start with a best effort, then try it out. I continue to adjust it until it seems to work. That's been my process for getting back to Shu.

Shu-Ha-Ri is a useful metaphor for explaining how people learn. But I've started to realize that there's a bit of a process to follow to get to Shu instructions - getting oneself into Shu business so to speak.

If English is your first language, or one you're pretty strong at, you'll get the "Shu business" pun. If you're old enough to know who Ed Sullivan is, you'll get it twice.

And, here's the self-serving bits - as if blogs were't self serving enough.

I'm happy to be teaching a first two-day public course for the Software Productivity Center on Agile Product Management on July 30th and 31st 2007. My goal with the course is to introduce the simple modeling, planning, and tactical Agile software development management approaches that I believe are best practice. It's not called an Agile requirements class, or an Agile customer class, although you could think of it as both or either.

As I said above, value comes from using software, not just delivering it. Agile development approaches are great delivery mechanisms, the very best as far as I'm concerned. But, it's the product - the thing we're delivering that's the most important. The SPC class focuses on figuring out what to build, and how to work with those who know how to build it. Assuming developers and others in Agile development know how to build software right, this class is about how to build the right software.

I've got upcoming half day-classes at Dr. Dobb's Architecture and Design World, Agile 2007, SD Best Practices, and OOPSLA. If you're attending any of these conferences, please come say Hi. If you're willing to start an argument, I'll pay for coffee while we talk. ;-)

(If you want to start an argument and your name is Ron Jeffries, I give up. ;-) )

Upcoming teaching events:

Dirty hands required

Why user experience people need to roll up their sleeves and get their hands dirty in development to get the best results.

In an email exchange with a friend this morning he was speaking about his involvement on a soon to be released product. He's been working on that product to design its user experience. He'd recently made a tactical change that I'm beginning to consider critical for the success of a software product.

In support of my friend's user experience work he'd built user interface prototypes, storyboarded usage scenarios, and validated those prototypes with prospective end users. All seemed well. But something funny happened on the way to implementation. The team members building the product had their own ideas about what the product should be. And those considering the direction of the product believed that a strategy change was in order. If you're a fan of Garrett's Elements model, you know that a strategy change changes everything.

There wasn't time for the team to go back an re-create UI design. The team was composed of really sharp people. I know most of them, and they truly are rocket-science smart software designers and developers. They succeeded in creating a product that was technically sound and innovative, but only sorta usable, and, well, not so sexy.

Meanwhile, the release date looms closer.

Give up and get started

After several rounds of reviewing the product and giving specific feedback on how to change it to make it better, the decision was made to give up.

By give up I mean for my friend to give up on giving feedback, roll up his sleeves and get his hands dirty in the development of the software. For him this meant taking ownership of CSS, directly editing XHTML, and where necessary editing underlying Ruby code. His hands were sorta dirty before - but much dirtier now. "I'm feeling much more positive [about the product]" my friend reports.

My friend's story is one I've hard, seen, and been a direct participant in many times - enough that I'm willing to declare it a critical success pattern for product design and development.

The tactical technical UI design pattern

Where I've seem product design be most effective, User Experience types are directly involved with day to day development.

They work on the requirements side to help define what the product does. They collaborate with developers to help them build functionality. No one expects the developers that build functionality to make it work well and look and feel good to use. The look and feel good part is done by a tactical, technical, user experience person.

This tactical technical UE person might be a developer by trade, or UI designer with enough technical background to load up the development environment and directly manipulate code to massage the user interface.

You really gotta do this.

The truth is that it's tough to predict exactly how the real code will behave once you start using it - see it animated and under your control as a user. Details about what should be in the user interface always arrive late - details that affect the layout and page or screen design. And, there's always late breaking great ideas. Stuff you thought of in the morning shower, or saw a competitor do in their website. There's no reason to follow your original design, if you've discovered something better.

What's more, a user interface design conceived by someone without detailed understanding of the tools used to construct it often suggests good, but expensive to implement designs.

There's a sweet-spot between good, and expensive to build that we're often looking for. Ideally, we hope to find a design that's best to use and cheapest to build. Without having a healthy understanding for how to build it, how could one find that spot? One would hope aggressive collaboration - even pairing at the development workstation might help.

The left-brain and right-brain in separate heads anti-pattern

I've often observed the "smell" in projects where the abilities to design the outside of the software, and the abilities to manipulate that design in code don't exist in the same head. I've seen lots of hours wasted, and lots of frustration trying to communicate the importance of moving this label 5 pixels to the left. I've seen developers angry when a designer asks them to relocate an element of a screen, only to reverse that decision after seeing it.

Sadly, fine grain design, the stuff that really makes a big difference in the perceived quality and actual usability of a product, requires lots of trial and error.

I have seen successful organizations where the designers were indeed separate people from the developers. But, the developers in these sorts of organizations, measured against the average developer, are strong designers. They can make fine-grained - 5-pixel-to-the-left - adjustments without prompting. They understand design well enough to be tolerant of the trial-and-error cycle. They understand design well enough to make changes based on very little guidance from designers. They understand design well enough to bring their own ideas and innovations to the product. While their left-brain may be a bit heavier than their right, their right is strong and fully engaged - and supported by design knowledge, skill and practice.

Good UI design can't be communicated in a document

I don't believe a good UI design can be communicated in a document. It may look good on paper. But the translation of that design to a working product will always result in some change - changing not easily predicted and written in the document.

Staff a tactical, technical designer

If you want your product design and development to be effective, put someone on staff who's both a strong designer and technically capable of making design changes to the product directly.

If you're a frustrated designer, look for a way to roll your sleeves up and get your hands dirty. Can you learn the technical skills yourself? Can you collaborate with a developer who has the right raw material to become a good designer?

If you've had success with your product by having tactical, technical UI designers on staff, I'd like to hear about it. If you've had success without them, I'd like to hear about how your process works to accommodate that. And, if you struggle with the connection between UI design and product implementation, I'd love to hear some horror stories. Please get in touch with me.

Requirements considered harmful

Why requirements in software development harm collaboration, stunt innovation, and threaten the quality of our products.

I wish I could take credit for first publishing a quote like this. But it was Kent Beck who actually did in his 2nd edition of Extreme Programming Explained.

Let me see if I can explain why the word "requirement" is just plain wrong.

When faced with challenges or in pursuit of a goal we decide on a course of action

I suspect you're reading this because you're somehow involved with software development, and Agile development in particular. In software development, we build tools for other people to use. When done well, the software we eventually release will be used by people to overcome a challenge or reach a goal. If the software doesn't do that, it was unsuccessful.

For businesses, challenges or goals often boil down to increasing profitability. Sometimes that takes the form of building more appealing products to sell, or supporting a necessary process to make it more efficient thus reducing costs.

There's lots of ways to make money, and lots of ways to reduce cost. So, exactly how we do either takes a bit of thought, deliberation, and finally some decision on a course of action.

The software we eventually build is the compounding of a great number of decisions

If the motivation for building software originated as some business objective, the person with that objective made a decision that placed software somewhere in the solution.

Assume for instance I'd like to build a new consumer product. I'm doing this because I've identified a need in the market - a group of users with an unmet goal, or a goal I believe I can meet better. I'm not in this purely for fun, so I need to make money selling software to meet their goal.

The product to build and user constituencies to serve were decisions I made.

I then need to make some decisions about what the product should do. I might look at the products competitors to see what they do. I might look closely at my target audience to understand what their problems are. I want to understand how my software will solve their problems, and very importantly, how many features it needs to have to convince them it will solve their problems - otherwise they won't buy it. (I tried to get at the idea of features that support buying decisions vs. features that support use in designing software for two-headed people.)

Once I've decided on the functionality I need to have, I need to make some decisions about how people might use the software. For the software to support my user's work well, I need to understand that work, and make decisions on how to organize screens and stuff in screens to best support that work.

My users are a picky lot. They expect the software to be esthetically pleasing, so I'll make decisions about how the software looks and behaves keeping my customer's esthetics in mind.

I can't please everyone, so I'll have to make some tough decisions. I might have chosen the wrong work to support - and consequently the wrong features. I might have misjudged my customer's esthetic sense and made choices that make the product not so desirable.

When I eventually sit down to write code, I've got to make lots of decisions about programming languages, databases, client type - browser based or rich, etc..

I still need to make lots of fine grain decisions about fonts on screens, text in error messages, and layout for stuff that prints.

I'm getting nervous. I've made so many decisions that depend on each other here. Most of these decisions were made on the back of previous decisions. How can I know if they were good decisions?

I don't intend to develop this software myself, so I've hired a development team. The development team asks me for my "requirements." I assume they're asking me for marching instructions - for me to tell them what to build. They must be referring to all the decisions I've made up till now - and I've made a lot of them.

"Requirement" is a label we put on our decisions

These were decisions made by fallible humans. The may not be correct.

The reason requirements in software development are hard is because they are decisions. The reason that so often they need to be run by everyone is because everyone wants in on the decision. The reason they're so hard to validate is because given the same facts, different people make different decisions – let alone given different facts. The reason requirements change is because decisions change. They change when we learn new facts that lead us to believe we could have made a better decision.

Decisions and requirements build on each other

In my story above, my choice of user constituencies was based on the product I believed I could create and the need I believed I could fill. The functionality was based on what I believe those people need. The technical decisions on programming language, browser based or not, database, stuff like that were made based on who I believed my users were, how I believed they'd use it, and the technology choices I understood I had at the time.

In the requirements world functional requirements are based on business requirements, technical requirements on functional requirements.

Whether we're talking requirements or decisions you can see that if I've got a bad one upstream, the one's based on it will be bad as well.

Giving requirements stops collaboration

Let's look at the word requirement, and the word decision. I'll throw them out along with a brainstorming of a number of words that I'd place in the same category.

requirement	decision
mandate	solution
order	problem
necessary	goal
indispensable	creation
non-negotiable	hope
indisputable	idea
contractual	discussed
final	reversible
blame	made by people
irreversible	attribute-able
absolute	explainable
consider as fact	fallible
change is consider to be process failure	change is natural over time

I guess it's not surprising that the lists vary. Aside from the obvious reason: that I made of the lists and I've obviously got an axe to grind, "requirement" and "decision" aren't synonyms. Both words characterize a piece of information. "Decision" describes an idea arrived at by a person or group usually after some consideration of multiple options, where "requirement" describes a contractual arrangement between one person or group and another.

Requirement is the word I label my decision with when I want to request you do something. By placing the word requirement on it, I let you know that the decision's been made, and you needn't concern yourself with it, other than to meet my requirement. Any conversation we have will be about the details of my decision. We're not working together to make it - it's been made. It's a requirement.

But, calling it a requirement gives me an uneasy feeling. These were tough decisions to make, and although I feel mostly confident in them, they could be wrong. By labeling them requirements, I now feel they must be right.

Asking for requirements avoids responsibility

Said by Fred Brooks in his 1987 essay "No Silver Bullet." Notice Fred didn't say the hardest part was the requirements, but the deciding. He does however say this in a discussion about requirements where he later goes on to say "Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy."

Since it's difficult to decide what to build, and since decisions are based on decisions, it's often likely that in a pile of decisions there's a few that are just bad decisions. Figuring out which are bad is difficult. By difficult, I mean darn near impossible.

Asking for those decisions as requirements avoids the difficulty of figuring out which are wrong by placing all the responsibility on to the person what made them. By calling them "requirements" we ask this person to take full responsibility for their decisions. We're not collaborators. We're not here to help.

Taking responsibility for one's decisions is usually a good thing. However requirements documents have an aptitude for anonymizing decisions - for obfuscating the person or people who made them, and the motivations for those decisions. Sadly, the net result is no one taking responsibility. And often no one to even ask exactly who decided this was a requirement and why.

Even sadder is when the wrong product is built as a result of failing to understand why specific decisions were made.

Adopting a process that uses "requirements" adopts the assumption we could identify correct requirements, and the resulting risks taken on with that assumption. "Requirements" are risky things.

Requirements come from outside, not inside

Now, at times, there is a place for requirements. Healthcare, banking, and a variety of other industries all have regulatory requirements. Not meeting these can result in bad consequences for our product.

But, these requirements are decisions just the same. Just like other decisions sometimes they're bad. Sometimes they're reversed. Sometimes they change.

It may not help much to know the basis for these decisions made by others resulting in requirements for you, since you can't likely changes them if they're bad decisions. (Or can you?)

These sorts of requirements come from the outside. These are decisions that aren't easily questioned, explained, or sometimes even understood. They may be a necessary constraint coming into our organization from the outside.

There's no reason to stand for the same level of inflexibility or lack of collaboration inside our organization.

Stop using that word and start collaborating to solve problems

At the end of the day, it's not the word "requirement" that does damage to software development, it's the ideas and process that often come with it.

My concern is the lack of collaboration that often goes into decisions. Or some using the concept to avoid really understanding the people who will use their software and the problems their software solves. Or, evaluating the product you choose to build on the basis of requirements being met, and not on the bases of user or business objectives being met or problems being solved. In the end, everyone in the organization pays.

I often host collaborative requirements worksessions. (Yes I do use the word.) I'll often start worksession by writing on a whiteboard "requirement = decision." I'll start by saying "We're hear to understand out goals, and together make the best decisions on how to reach them."

I've seen environments where "requirements" were used in a process-healthy way, where requirements were considered more as decisions, and participants were aware of the details what went into those decisions. But these environments are the exception rather than the rule.

The decisions we make about our software should never reach the state of "mandate." They should never be unquestionable. They should never stop being measured against their ability to effectively solve business problems. They should always be recognized as fallible.

If I had my way, we'd stop using that word. The baggage is too much for me.

But I don't know what word I'd replace it with. Perhaps user story? But, that uses one of the other unfortunate words in software, "user." And what about all the decisions I make that aren't so closely related to the person using the software?

I'm using the word "decisions" or the phrase "design decisions." Try out another word around your company and tell me what works for you.

The mystery of the shrinking story

How the push to reduce story size pulls us farther from user goals and forces more up-front-design into Agile processes

I've noticed a troubling trend in Agile Development over the past few years - that's the decrease in recommended size of a user story.

It's not so much the decrease in size that's concerning, but the lack of practices and techniques to support this approach. And the misunderstanding from Agile practitioners dead-set against big-design-up-front that getting those little stories forces lots of up-front design.

In Agile development the user story as originally described in extreme programming is "one thing the customer wants the system to do." Ideally it would be written on an index card. It's definitely not a requirement - contrary to the wikipedia definition and many practitioner's misconceptions. I see it as an item in a to-do list - a discussion to have about a need or desire a user or stakeholder of the system has. What we really intend to build isn't written on the card. It comes from the conversation we have as a team about the story. Ideally, we'd write acceptance tests to serve as specifications and to validate that we got what we wanted.

Stories have engineering constraints built in

That user story idea sounds simple enough. Now, enter the villain in this story: engineering constraints. I started with XP back in 2000. At that time the user story had a definition like this:

Notice the engineering constraint there: "estimable between one and five ideal programming weeks." It's not a tough constraint - since an ideal week usually has a ratio of between 2:1 and 3:1 with a calendar week. That means we're talking about work that a pair of developers may take as long as 15 weeks to complete. That's up to 75 man days for those doing the math - 150 if you double it for pairing.

It's really quite easy for someone to imagine something useful the system could do for them that could be built by a developer in that amount of time. And, it's enough time for developers and customers to collaborate together to figure out exactly what to build, even enough time to make and reverse a few mistakes. To get that much built will likely take a fair bit of collaboration during the development iteration to decide on all the details.

Now when I cite this definition of a user story in an Agile context today, most developers are in shock. Many think I'm making it up. That's partly why I've included the image of the glossary definition of Story from Beck's 1st edition Extreme Programming Explained. It seems to be conventional wisdom today that a user story shouldn't be bigger than about 3 ideal days. That might translate to as much as 9 man days by a pair of developers.

Size based on the time for developers to complete is an interesting constraint that may not have much to do with what the user of the software hopes to achieve. One project I worked on in the past was developing medical software. The heavy regulatory environment and large number of dependent legacy systems to integrate with meant that we couldn't have gotten much done in a 3 day user story. So tougher development environments or more complex domains might mean that a small story gets less functional software for your customers.

Five weeks is now three days! That's a big drop over the past 6 or 7 years. Why did that happen? And, what are the consequences?

There's benefit in keeping stories small

I agree that a small story size is a good idea. There are lots of benefits from having smaller stories.

• From a user and usage perspective, reducing the story size forces me to understand users and usage better. It forces me to separate what really is valuable or useful to the users from what's merely interesting.

• From a release management perspective having lots of smaller stories allows us more flexibility with planning, prioritizing, and cutting scope.

• From a development and detailed design perspective, a smaller story often implies we know more about what to build - there's less unknown, less risk – less risk of the development work mushrooming into something much larger.

Is it these sorts of benefits that pushed stories down so much in size?

Did you catch the up front design there? Statements like "knowing more about what to build" implies that someone spent whatever time was necessary to figure out what to build.

When stories were large - estimated in weeks, and up to 5 weeks at that, not many details were resolved to give those estimates. Those details were deferred for resolution later – immediately before or during the development iteration. Developers were expected to collaborate with those in a customer role to arrive at what those details were.

Today, if we want story estimates to come in smaller, we need to figure out those details beforehand, and compartmentalize each of those details into their own user stories. That work is the design-up-front. And the push to smaller stories forces it to happen earlier - ahead of the development iteration.

By itself that's not good or bad. What often is bad is that all the figuring out of what to build and how to decompose it often happens inside the customer team and outside of earshot of and collaboration with development. That means those in our customer role, often people unfamiliar with building software, struggle through it without practices to support them. And, the developers who get these user stories miss out on a lot of context they might have had back when stories were large and conversation was more mandatory.

The goal-task-tool dependency - how stories help users do work to reach goals

There's a simple hierarchy I keep in mind when designing software - the goal-task-tool hierarchy. People or businesses want software to achieve some goal or objective or solve some problem. For them the software is a tool that makes the actual work done to achieve that goal or solve that problem go better. Other tools might be paper forms, telephones, or other physical things used by people in support of a process that helps them achieve their goals or eliminate their pain.

The software we're building is a tool. The quality of a tool, from the user's perspective, is measured based on its ability to effectively help reach their objectives.

The user story format described in Cohn's User Stories Applied is a good one.

That story format has user, task, and goal elements in it that make me happy. And it defers deciding exactly what the tool/software is till later.

To make a story smaller, we've got two choices:

1. decomposing big tasks or business processes into smaller tasks or business processes
2. deciding what the software should look like to support user's tasks or business process - designing the outside of the software – then cutting that finished design up into pieces to implement.

Both take time and expertise. And, there are risks with both approaches.

Decomposing the work

Decomposing tasks into smaller tasks means we've got to keep some idea of what the big picture is - what the real goals of the user are, and how the little task in this story fits into a the context of a bigger task or process. A model that relates stories together and helps people visualize that workflow is helpful here. I've had good luck doing that in the past using big workflow models like this and this, or writing user scenarios that spin smaller user stories into bigger stories. We could use use-cases here, or other forms of workflow modeling.

Decomposing the tool

The second approach, deciding what the application looks and behaves like early, I think is the most risky - and involves the most upfront work. In this approach we've had to decide up-front – and hastily at that – what tool our users need to solve their problems - then slice that tool up the way a butcher slices a side of beef. We then build each cut a piece at a time.

Unlike the butcher whose goal is to cut up meat for a lot of people's dinner… we're trying to reassemble a cow from its parts and hope it looks like one when we're done. We've also decided the solution is a cow… not a chicken, pig, or eggplant. Our user stories become about building a cow and not about what the user's goals are and what he's doing. Is the user's goal to get milk to make cheese? to eat a healthy meal at some later date? or to pull a plow? We don't know anymore. All our stories are about chuck roasts and flank steaks. All our design was done up front - the design that's done to figure out what product could best meet (or meat) the user's needs.

Reducing story size benefits from adding additional practices to mitigate risk

At some time we do need to figure out what to build. But ideally we defer that time till the latest responsible moment, and we never lose sight of our users, their goals, and the work they will use this software for to meet their needs.

There are a lot of good reasons to have smaller stories.

• Do they need to all be small up front? Can we start with bigger stories - stories estimated in weeks, then decompose them as needed?

• Can we build big models to connect our stories into an understandable workflow?

• Can we build user models to help us not forget who the users are and why they use this software?

You'll notice if you adopt these strategies you can start projects quicker because you can write fewer, bigger story cards initially and decompose as you get closer to building the software. It helps to keep track of the relationship between those big stories and the smaller stories they were decomposed to. In Cohn's User Stories Applied and Agile Estimating and Planning he describes sort of a story decomposition hierarchy of theme -> epic -> story -> task. The important idea here is that big stories are useful sometimes, and less useful other times.

You might also notice that you won't have to write as much on your cards since if you have a good user model with goals on it and a good task model; you won't have to keep rewriting those same users and goals over and over on each card.

Take the approach I recommend and model users and their workflow as tasks, then design user interface support tasks as needed. But, don't fall in love with your user interface. As you layer in tasks your user needs to accomplish, the user interface will need to change along with it.

These strategies help mitigate the risks we take on by moving to smaller stories, and help us avoid the temptation of deciding too early how the software should look and behave.

Before, during, and after-people

an unfair characterization of user experience professionals

Three personalities in the user experience community

This article is about how I stereotype people in the user experience community. It's not very nice to stereotype or categorize people. But, Ux people are in the business of it. Most of our user models like personas, roles, and profiles help to generalize our understanding of our users. It's only fair to turn that back in on ourselves.

I generally use three categorizations – before-people, during-people, and after-people.

Before-people worry about problem understanding and the response to that understanding

Within the Ux community you'll find people who spend lots of time thinking about the users, the way they think, work, and what their problems are. The before-people will spend time talking with them, observing them, and studying the users. They'll use nifty models like personas or affinity diagrams to capture and communicate the results of their research.

Given that researched understanding of users, their problems and goals, before-people will then seek to describe the type of software or other tool that might be valuable to those users. They might describe that solution with scenarios, storyboards, UI wireframes - usually low fidelity visualizations of the software or tool.

These folks have sort of a scientist's and inventor's personality combined. But not in a bad way. They're often outgoing and energetic. They're very observant about what's going on around them. They'll notice all the scraps of paper on your desk and ask you what you use them for.

Interaction designers often fit into this space. Sometimes information architects will as well. Sometimes we might call them general user-centered designers.

You'll want these sorts of people involved long before you decide what software to build. They'll help you understand what that software should be - assuming you should be building software at all. You want them involved before.

There's an assertion hidden in here that the software requirements are a product of this research and design. But, I'll confuse you with that discussion at another time.

During-people worry about the usability and aesthetic aspects of the solution

Given that we've agreed to build a piece of software or some other tool, how does that tool look and work specifically? What colors will we use? What shape will we use on buttons or controls? What aesthetics contribute to both the usability and experience of the user as they use the product to meet their goals? These are the concerns of a during-person.

You'll find people within the Ux community that focus on specific aspects of user interface design such as visual design, detailed user interactions - that stuff that makes the software really sexy. And ultimately the stuff we really see and touch. Since this part of the design is the stuff we see and touch, this is the type of "UI person" a Ux professional is most likely to be mistaken for.

The Ux practitioners with their head in this place are often visual designers. They may also be hardcore software developers who focus on the design of specific UI widgets or user interactions - possibly things like cool scriptaculous effects.

They may not have to know much about the brand of breakfast cereal their users eat - they may not be that interested in all the user research a before-dude did to identify the software being designed. Consequently, when asked to suggest a software solution to a user's problem, they might not be up to that task.

These are the creative types. The group referred to as the "ponytails" by some, but not in a bad way. They're the ones peering at you over the lid of their MacBook while sipping a double espresso.

You want one of these types involved during the detailed design and development of your software. They're tactical. They'll make a big difference in the perceived quality of the software.

After-people worry about validating and improving the quality of a solution

Given some software solution, we need to understand if users really can use it to meet their goals. We'd figure this out by, you guessed it, watching users try to use it to reach their goals. This is usability testing.

You'll find people in the Ux community who are excellent at observing people using a tool and identifying where their problems are and how the software or tool might be altered to better meet the users' needs. Those who have observed many users using software have come up with ways to asses the usability of software without actually observing its use based on the most common usability problems encountered in the past.

These folks are critical and calculating, but not in a bad way. You'll find them aware of and sensitive to the slightest details in a piece of software or some other tool. They'll identify design issues in your car, calendar, or coffee mug. They may not be best at figuring out what the solution should be, or making it look sexy, but they can tell you if the solution is effective or not - and how to make it more effective.

Usability engineers fit the description of the after-person. You'll want them involved after you've produced some sort of solution - either finished software or more preferably a prototype of what you intend to build. They'll tell you if the software is really living up to its intentions.

The personality pie chart

No one fits squarely into just one of these categories. In fact, everyone has a bit of all these personalities, concerns, and skills. But I do find that different Ux people have a magnetic pull toward one of these three personalities.

Me, I'm about 55% before, 30% during and 15% after - so I'm mostly a before-dude. It's just where my interest and concern is. I have a so-so attention to detail. My visual design skills are adequate. But, I feel very strong at identifying problems, goals, and potential solutions.

The right personality for the right time

When you're in the throes of solving a design problem, you need to put the right personality to task. If you're just one person tasked with assessing the usability of a piece of software, you'll need to tap into your inner-after-person. If you're a large organization with different people in different roles, make sure the personality types in your usability lab are best suited to the task at hand.

If all this stuff is new to you, and the idea of a UI person who doesn't actually design UI seems crazy, knowing about these personalities should help. You may know a before- or after-person and have been puzzled in the past about how they do their job while completely lacking the ability to make cool buttons on PhotoShop.

Terminology pollution leads to responsibility confusion

There's lots of language to describe what people do in the user experience space. I've been confused by it for years. Here's a list of common Ux job titles - and not necessarily a comprehensive one.

• User Experience Professional
• User Centered Designer (UCD)
• Human Computer Interaction Designer (HCI)
• Computer Human Interaction Designer (CHI) - what's with the HCI/CHI thing anyway?
• Interaction Designer
• Information Architect
• Visual Designer
• Usability Engineer
• Human Factors Professional
• UI people

You'll find that often these people do different things, work differently, and think differently. I find that those who aren't familiar with the definitions of all these roles and terms tend to roll all of them together into "UI people" and expect these sorts of folks to make bad software user interface look better.

I find that people within the user experience community are often inconsistent about what these terms refer to. It's been over the past year that I've finally developed some working definitions for myself. (You can find them in the slides of this talk - starting on slide 19.) I'm sure these definitions aren't accurate for everyone, but they help me keep my world straight.

When a term or job title fails me, I can usually classify a person as a before, during, or after. That helps me quickly guess at their skills and sensitivity - and quickly guess at where and when they'd be most interested in participating in our project.