Is there room for UCD in Agile? part 3

So now we are at Question 3:

Do the UI stories count as "done", even when no software has been written?


"Count" is the operative word here. Do we mean "count" as in "keep track" or "tick off on a list" or do we mean "count" as in adding up some numbers and coming to a conclusion about actuals vs. estimates?

The purpose of saying a story is Done, is to have a means of measuring the team's velocity -- how much working software gets built on average per iteration/ sprint. Thus, in theory, you only really care about Done if the story is a coding story.

But you still need some way of determining if the flow of stories out of the backlog will impede the team's velocity. Now we're talking lean. Are stories getting delivered into the "ready-to-build" backlog fast enough so that the development team can always pull something off the backlog given their average velocity? Or are the developers going to sit around with nothing to do because stories won't be ready? Or better yet, can we move on to the next phase early because we're going to blow through / complete all the stories originally planned for this sprint/phase?

It is important to see the status of those higher-level analysis and UI research tasks that precede the coding stories. If UI work was substantial enough to make it visible as a "story" then you have to be able to say if it is not started, in-progress, or done, and have target expected completion dates so the team can get some kind of assurance about how and when the backlog may grow or shrink.

You can even assign and track analysis estimates and velocity in the same way that you track development velocity. But don't mix the two things together; the velocities are measuring completely different things.

UI research and the subsequent problem definition and solution finding (design thinking) will either add new coding stories, provide details for existing stories, or remove stories. Where the research provides new details for existing stories, that information will increase or decrease the stories's complexity. Likewise, adding and removing stories changes the estimated amount of effort in the backlog.

Being able to see when UI findings are likely to conclude gives the team information about future events that could affect the backlog and helps everyone roadmap the project's progress.

The team needs to be able to see it like this: Our velocity is V. The total point value of our backlog is 4xV so the project should complete in 4 sprints BUT, we still have two UI research tasks to complete and our experience so far on this project indicates that those tasks could add as much as 1xV each in changes to the backlog. So we have a total potential story point increase of 2xV. Therefore, as of today, our best estimate of finishing is in 5 sprints but we may need as many as 6.

(If you are curious about assigning story points for tracking velocity, here's one nice way to do it.)

Is there room for UCD in Agile? part 2

In my last post, I started to cover some ground on how Agile and UCD can fit together. These postings come from a discussion on agile usability in which Robert Biddle of Carleton University, asked me three very good questions.

Q1: are the UI designers and programmers within the same team but do different kinds of tasks, or do they do both?

Q2: what are the UI stories (or backlog items) like, especially for user research?

Q3: do the UI stories count as "done", even when no software has been written?

My answer to Question 1 essentially elaborates on my previous post: UI designers and UI programmers are just another flavor of business analyst or programmer and they would collaborate with the other analysts and programmers on all the tasks that need to be done including user research and usability testing.

For example, a team could have a person who has skills in UI design and UI programming. That person could pair up with another analyst to do user research in one iteration, then pair up with a developer to code the UI part of a story(s) in another iteration. A team may also have a person who is a UI designer and experienced in user research but not experienced in UI programming. That type of person would stay completely in the analyst / customer proxy role doing things like user research, product design, acceptance testing, facilitating showcases with the stakeholders, and also any needed product documentation.

The other programmers on the team would also pair up with UCD analysts as needed to have conversations, investigate solutions to a problem interface, and conduct or witness research into the user experience.

Q2: what are the UI stories (or backlog items) like, especially for user research?

We have to be careful with the term "story". "Story" is a thing that developers implement. "Tasks" are things that have to be done to get stories through the pipeline. Tasks are activities people do to figure out what the story should be, realize the story in code, or verify the story is done. You have a UI story if you have something that can be stated like this:

As a mother, I want to be able to search for a doctor who can treat my child's condition and practices close to my home. Acceptance: The search functionality must be easy to find on the home page, you can search by all or part of a medical term (e.g., cancer, scoliosis, juvenile diabetes) and/or a location (city, state, zip), the search results will include the doctor's names, specialities, location(s) and photo.

You have a UI task if you have something that can be stated like this:

Interview/observe 6-10 mothers of children under the age of ten to understand how they would search for and find a doctor for their child on the internet.

Or this:

Interview/observe 6-10 mothers of children under the age of ten to gather information on their expectations for a children's hospital website.

Or this:
Analyze interview results and identify new candidate stories for inclusion in the current or future development phases.

You definitely make the coding stories visible in the master story list and track their progress, but you may not build a backlog of all of the tasks. High-level tasks might be treated "as if" they were stories so it is easy for the entire team to be aware of overall progress and activities for the iteration, but your tracking system would have some type of physical distinction between the analysis/UI tasks and the coding stories.

For example, your information radiator/story wall would likely use color or parallel tracks to distinguish coding stories from other activities. The development track might show stories 2, 3, and 4 in play while your analysis/UI track might show that story 1 is out for customer and UI acceptance testing, detailed requirements discovery is starting for story 5, and user research (UI task) relevant for proposed backlog stories 6, 8 and 9 is in-progress.

A lot of tasks are not made visible because it's just too much noise. But people still report status and blockages in daily stand-ups -- I'm going to be late finalizing the requirements for story 5 because I can't get a meeting with Mr. Y; we need to get the XML spec for the interface to system G before we can complete story 3; our user interviews are proceeding on schedule and we have no problems to report.

I'll cover question 3 in another post since that also has a long-ish answer.

Is there room for UCD in Agile?

I'm a member of an agile usability discussion group. There has been a lot of discussion lately about how and whether designers and UCD people can work within an Agile project. There is a lot of concern that methods and aproaches may not mesh -- that Agile starts developing and releasing stuff long before the designer can complete their diagnosis of the problem and create an effective solution.

for most of my time at ThoughtWorks, we did not have any UCD staff but that has changed over the last year or so. Still, every project is different and we shape it according to what works for the situation.


Sometimes, there is no UCD involvement and business analysts and developers just have to make things up based on what they see as making sense and where the client is coming from (often these are applications for the clients internal use ). Sometimes there are projects where the client hired a designer independently of bringing TW in for the implementation and their design is pretty much a static requirement in place at the start or delivered part way through (not very good). And then there are projects where we can have our own UCD person on-board or the outside design firm is committed to working as part of the team through the life of the project. That's when it gets good.

Ideally, there is one or more UCD-skilled person(s) involved on the team through the life of the project. When you have this, the UCD person is utilizing their skills as they play some combination of other roles: product owner/customer, business analyst/SME, developer. This is very much like the way a business analyst would also fit into team.


A business analyst has to be able to understand the business operationally, grasp the strategic objectives of the stakeholders; interview stakeholders and customers/users to discover and verify requirements; be an advocate on the team for the customer/stakeholders; be an advocate for the strategic objectives (sometimes even stakeholders lose track of the greater goals); know enough about technology to have an intelligent conversation with developers so they can advocate back to the stakeholders when choices get hard; and maybe even sometimes do something technical themselves, plus be able to specify and conduct effective acceptance tests so everyone can be assured the story is Done when it's done.

That is not so very different from what the UCD person wants to achieve. Given that, the UCD member of the team is just another flavor of analyst /developer on the team. They concentrate on their specialty but they also collaborate on other just-in-time project tasks as appropriate. For example, maybe doing javascript coding or conducting showcases with the stakeholders, or writing stories and acceptance tests. Programmers also pair up with the UCD analysts as needed to have conversations, investigate technical issues, or research the business problem.

In my next post(s), I'll discuss three very specific questions about how this can work.

Great Leaps Forward

Last month, the Financial Times ran an excellent editorial about government and business activities that exhibit the Great Leap Forward syndrome.

The author, economist John Kay, uses the example of Mao Tse-Tung's attempt to restructure China's economic base to illuminate why large-scale software projects also, often end in failure.

"Great Leap Forward syndrome begins with an aspiration to remedy serious past failure with unprecedented future success...." he writes. "...In a Great Leap Forward, the wish is father to the thought. There is no recognition that past failure means that future success will be hard to achieve."

It's a short column but one that, in the second to last paragraph, effectively makes the case for an agile approach.

My previous project

Here's a little self-promotion:

Martin Fowler had a very nice write-up about my last project, the one that's still going without me. He said, "It's a favorite of mine because it exhibits an important property of my preferred view of software development: a long term support of a business function enabled by a well-designed code-base. The fact that they are still adding useful business value after ten years is a big dollop of kudos."

He also referenced a podcast about our project, Keeping Grey Code Fit, in which I am one of the panelists.

I didn't have any thing to do with that well-designed code base. We had and still have, a great team of developers. But I will take some credit for ensuring that the stuff we added over the past few years still had business value.

For example, my friend and fellow TWer, Josh Evnin, and I worked with members of the client's staff to do two contextual inquiries with the end users. This research revealed a sizeable list of quick-payoff process and software improvements, and helped the client avoid some expensive decisions.

We gave a presentation about this work at Agile 2008. The experience report is available through IEEE for $19 but if you are a registered user, the .pdf handout of our presentation, Are You Sure, Really: A Contextual Approach to Agile User Research is on the Agile 2008 wiki. Or you can contact me for a copy.

So what do I want to be next?

In my first post, I talked about being "on the beach", in-between projects. When you're on the beach you get a lot of time to reflect about what you want to do next. That's because just about everybody you see will ask you two kinds of questions: "Are you on the beach?" or "Are you still on the beach?" And then, "What do you think you'll do next?" or "What do you want to do next?"
For example, just the other day I encountered two interesting, fairly equivalent versions of this question. A TW friend and I were headed to get some lunch. "Would you want to be an Agile coach for your next assignment?" she asked. Later that day, I was filling out a questionaire regarding a possible assignment in India as trainer for our internal education program. The form asked, "What would be your ideal experience as a trainer?"

Interesting. What would be my ideal experience of an experience I had never had before?

Let's think about this awhile and put it into perspective. You've never been to the moon. What would be your ideal experience of a moon trip? You've never hiked Spain's Camino de Santiago. What would be your ideal experience of that? You've never driven Route 66. You've never dog-sledded to the North Pole, worked a commercial fishing boat in Alaska, given birth to triplets, or manned an election campaign office, etc. etc.

If you've never done something before, how do you have an ideal of that experience?

And then it comes to me....

You can talk to other people who have done it and you can read guide books or other resources and find films or videos about the thing. You can get all sorts of advice and ideas and work out a really good plan for how things should go and what you'll do at each key milestone. You can even chart it out with timeboxes and checklists and make reservations for all the big events and must-see/do highlights...but hey, that's just big design upfront, isn't it? That's just waterfall living.

I waterfalled myself and my partner around Hawaii's Big Island in one day but we had to get halfway into the plan before it was clear that plan was too ambitious and we were not going to have an ideal experience. In hindsight, I could work out a much better vacation schedule.

Yep, I firmly believe you have to have an experience first before you can be in any position to decide what would be an ideal version of that experience.

Until you start doing that new thing you've never done before, you have no qualifications to judge what would compose an "ideal" version of that thing. You have to start from personal experience, evaluate events, acknowledge what worked (is working) well, adjust whatever is in your power to improve and leave lots of open space to shift directions and change plans. That's the agile way.

How I learned to let go and love life on the beach

Hi. I'm Marjorie Pries and this is my first blog post. I'm a business analyst / project manager / iteration manager / utility player (honest, my business card says, "Utility Infielder" ) for ThoughtWorks, Inc. in Chicago.

I've been in software development since 1992 and I've been with ThoughtWorks since June 2000. Today, I'm "on the beach." That means I'm in-between projects ... non-billable ... unassigned ... waiting for something to come in. I've been on the beach since the end of January and you know what, I have never been on the beach with ThoughtWorks before.

It has nothing to do with me, or the project I was on. We still have that client but they don't have the same budget they had last year, and it just made sense for me to come off. It gave a really good guy a chance to stretch and take on some different responsibilities and what the heck, I'm the utility infielder, at any other time it would have been easy to fit me into something new right away.

So five weeks later, what can I say about being on the beach, this long? I was really surprised how much of a grieving aspect there was to my days. The first week was a lot of sorting through mementos, archiving documents and elements, updating the former team wiki, and just generally letting all those wheels of concern and ideation roll to a halt. The second week I shadowed on another project just to see what was what. It was mostly excruciatingly boring (my IM avatar during that week was a chattering skull in a dungeon with a tortoise) but I was still feeling grief. A great emptiness emerged from no longer having that great project and its great people (TWers and the client's) in the center of my worklife.

I spent a week in Oregon with my mother-in-law (well, my live-in partner's mother). We shopped everyday for things she had vague ideas about but couldn't find on her own ...that's some real analysis work there. It helped! Also reading a really good detective story, The Girl with the Dragon Tattoo. But still some emptiness lingered.

Now I'm five weeks into it and over it. I dropped off my last folder of notes with the old team earlier this week, submitted a proposal for an Agile 2009 presentation, signed up for some conferences and classes, have some project prospects on the horizon, and even started blogging.

It's cool, and I feel I've made an important people management discovery. Downtime between projects is necessary! The longer the participation in the old project and the deeper the ties (to the project team and to the project strategy), the more a person needs downtime to let go, say good-bye, reflect on lessons learned, and focus on the new things they want to pick up. Two weeks is OK for lightweight gear-shifting but definitely a minimum of four to six weeks works better when the previous role was intense. If your organization can afford it, you must do it. The re-charge will certainly payback unforeseen benefits in the long run.