Thanks William That's a very valid point. What if the usability people wanted to dedicate an entire user story to doing usability stuff. From where would they get the business value given that its not a straightforward process to be able to quantify the business value where usability is concerned? Do you have any advice on working out the maths?   Regards Leina --- On Thu, 5/8/08, William Pietri <william@...> wrote: From: William Pietri <william@...> Subject: Re: [agile-usability] Agile UCD Velocity Points To: agile-usability@yahoogroups.com Date: Thursday, May 8, 2008, 4:41 PM Leina wrote: > If the usability people are going to build in usability acceptance > criteria into the user stories it will no doubt add extra work. > > Do they need to estimate that work, work out their own velocity and > build it into the user story? > One of the things I see teams struggle with during agile adoption is going from a team with formal roles to a more collaborative team. In the beginning, when people are role oriented, database work is done by the database guys, back-end development is done by the server-side specialists, front-end development is done by the web people, and usability is done by the human factors expert. I think this is a natural place to start, but should be looked at as something to move away from over time. I think each estimated story should have a single estimate that represents the whole team's estimate, including everything it takes to get to 100% done. However, when scheduling stories within iterations, the team should be sensitive to individual overload and burnout. During iterations, teams should be working together in ways that provide some cross-training. If not enough of that is happening, explicitly schedule it in the course of working on stories. E.g., get together with the front-end people, and work out the UI together. It will take a while, but eventually your team will pick up some usability skills, allowing the basic stuff to be done by a broad range of people. Then the team can adjust organically to stories with different workloads, making the concept of a team velocity much more real. William

Jared M. Spool wrote:
>
> My questions are this: In an agile project, *when* is time taken to
> initiate the vision? And, how does the team ensure, when the vision
> moves, that everyone "gets the memo"?

I think it emerges as part of planning and design. In that those are
distributed throughout the process, I think vision is too.

Some planning happens before iterations start. People have some notion
of why they're quitting their jobs to start a new company, or why
they're funding a project. The vision begins there.

A big chunk happens during story planning and scheduling. Typically,
teams have far more stories in the backlog than can ever be done. (If
that weren't true, it would be a giant red flag to me.) How do you
decide which ones go in?

On the teams I work with, that's generally done through discussion and
consensus. In figuring out whether to do X or Y, their shared vision is
part of what they use to decide. When they have trouble agreeing, it
forces them to surface and consider differences between individual visions.

Sometimes those differences are resolved quickly. Sometimes they get
settled through experiment. Sometimes they become long-running
questions, so that answering the question becomes part of the shared
purpose, part of the vision.

But I think another important part happens during more detailed design
and implementation of stories. Elements of the vision get transmitted
via product managers from the high-level planning meetings during the
design and construction of a given story. It happens every time somebody
asks why, and often even when they don't. Just as important, people
mainly focused on implementation feed back information and observations
that get incorporated globally.

Like design, like planning, like quality, I think vision is important
enough that you should never stop doing it. If the question is "when",
the answer is "always".

William

Austin Govella wrote:
> Agilistas claim you don't need vision: you'll figure
> it out when you get there.

Bullshit!  I'm and agilista and I claim that vision is crucial to
project excellence, whether the project is run in an agile fashion or not.

If you don't know where you're going, any road will take you there.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

• Put design ahead of development
• Share the design vision
• Effectively share user research with developers in a timely manner
• Gain a shared understanding of the design across the team
• Give the team ownership of the design in a manner that leverages the expertise of every team member (and the designer)

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
>  From what I've seen, doing user testing in the middle of a story is
> generally too painful, so teams will do it either before a story or,
> like yours, after.
>
> Doing it before gives you hard data that lets you specify a clear,
> easy-to-estimate UI that you have high confidence will be very usable.

We do both...paper prototyping and also software prototyping (we use
Axure RP Pro) prior to writing code, and then when the story is
finished we usability test the real thing. The real thing is never
exactly like the prototype, but doing the prototype means we can see
the big picture and get the flow right, what info is required where on
the interface, and this of course affects the back end and overall
design. Testing the real thing tweaks the little things mostly and the
better job we do of the prototype (in terms of usability) the less big
tweaking that is required.

> But how do you fit that into the agile cycle? Some teams do that with
> low-fidelity testing, like with paper prototypes. In that case, the
> testing never enters into the stream of stories; like other planning
> work, people do it as needed to keep the story queue full.

Strictly speaking we don't include the usability testing in the
development stories, and a story that depends upon usability testing
just won't get written until the prototyping has been done (in some
form or another). On the other end, when a story has been coded, we
don't "close" the story until the tweaking is done. Big tweaks get a
new story. This keeps the estimation realistic for the programmers.


> things. An advantage of this approach is that you can batch your
testing
> and do completed, in-context flows. For web shops, an even bigger
> advantage is that you can release and do A/B testing or just make
things
> live. Either way, that gives you statistical data that can complement,
> support, or drive your user testing.

Yes, absolutely this is what happens with us too.

>
>
> To make the usability-test-after approach work, I think you need three
> things. First, you have to be confident enough in your UI designs that
> the cost of building and tweaking later is lower than the cost of
> prototyping and then building. Second, your agile process cycles
have to
> be short enough that improvements and corrections can follow quickly on
> the original work. And third, there has to be enough rapport on the
> planning side that usability gets properly valued.

Again, right on the money.

susan

>
> Happily, agile methods like Scrum and Extreme Programming usually make
> all of those more true over time, so I see plenty of people using that
> approach successfully.
>
>
> William
>

--- In agile-usability@yahoogroups.com, "Jared M. Spool" <jspool@...>
wrote:
>
> I guess I'm wondering what the role of a 'vision' for the
> project is  in the Agile world.
> Jared

Very important, occasionally documented as a practice, but still
underutilized. Being underutilized doesn't mean it is not important.

Alistair

What if the usability people wanted to dedicate an entire user story to doing usability stuff.

From where would they get the business value given that its not a straightforward process to be able to quantify the business value where usability is concerned?

Do you have any advice on working out the maths?

The Client would supply the figures. So an example (developer) user story reads like so:   As a trainer I want to present training courses So that Company Z can improve resource utilisation by 10% (=£8K) If size = 8 Then difficulty rating =  business value / size = 100     The difficulty arises when you decide to write the user story from a usability angle:   As a trainer I want to present quality training courses (quality here means providing an enjoyable user experience) How do you measure the benefits to Company Z. In other words how do you put a value on enjoyment/user satisfaction?   Regards Leina --- On Thu, 5/8/08, William Pietri <william@...> wrote: From: William Pietri <william@...> Subject: Re: [agile-usability] Agile UCD Velocity Points To: agile-usability@yahoogroups.com Date: Thursday, May 8, 2008, 11:08 PM Interesting question, Leina! How does your organization measure business value for the other stories in the queue? William leina elgohari wrote: Thanks William That's a very valid point. What if the usability people wanted to dedicate an entire user story to doing usability stuff. From where would they get the business value given that its not a straightforward process to be able to quantify the business value where usability is concerned? Do you have any advice on working out the maths?   Regards Leina --- On Thu, 5/8/08, William Pietri <william@scissor. com> wrote: From: William Pietri <william@scissor. com> Subject: Re: [agile-usability] Agile UCD Velocity Points To: agile-usability@ yahoogroups. com Date: Thursday, May 8, 2008, 4:41 PM Leina wrote: > If the usability people are going to build in usability acceptance > criteria into the user stories it will no doubt add extra work. > > Do they need to estimate that work, work out their own velocity and > build it into the user story? > One of the things I see teams struggle with during agile adoption is going from a team with formal roles to a more collaborative team. In the beginning, when people are role oriented, database work is done by the database guys, back-end development is done by the server-side specialists, front-end development is done by the web people, and usability is done by the human factors expert. I think this is a natural place to start, but should be looked at as something to move away from over time. I think each estimated story should have a single estimate that represents the whole team's estimate, including everything it takes to get to 100% done. However, when scheduling stories within iterations, the team should be sensitive to individual overload and burnout. During iterations, teams should be working together in ways that provide some cross-training. If not enough of that is happening, explicitly schedule it in the course of working on stories. E.g., get together with the front-end people, and work out the UI together. It will take a while, but eventually your team will pick up some usability skills, allowing the basic stuff to be done by a broad range of people. Then the team can adjust organically to stories with different workloads, making the concept of a team velocity much more real. William

Hello Beth:

Well, this is one of the big problem I encounter on several project
teams. Sadly, it comes down to convincing your product owner /
customer / BA that the usability is just as important as the features
and that usability stories are included in the project backlog. If
they are important to the customer you may want to load a usability
story at least after the first sprint. At the end of the first sprint
you should have a working product. This will no doubt generate a ton
of feedback in a Sprint review. The trick is to make this story
independant and perhaps timebox it to 8 hours (or 12 hours) etc..
going into the story with the acceptance that it is a work and
progress. Then if the story is time boxed in such a way it shouldn't
mess up your predictors.


What you encountered below is something I've run into. Some agile
experts are going to tell you "leave the UI" out as long as possible.
That doesn't mean the UI, paper-prototypes, mocks, etc isn't evolving
as an outside process.

The root of the agile cycle and especially sprint planning is to
yield to the constraint. Generally this is the developers. So with
the exception of a developmental task aimed at the "UI layer" of
code. You probably won't see much in the line of usability stories.

Hopefully, you have a team of developers that are aware of exposing
UI functionality to your Interaction designers. That way the code is
not tightly coupled with the UI.

Keep in mind that agile is a process methodology. As such It's a
process that has a ton of best practices. Not all practices work for
every business unit. You have to find the perfect blend. If that
means tasking out UI / usability stories in your planning session so
they aren't forotten. That should be done.

As to including your "UI" in the definition of done. This can cause
problems. I'm still working through this one myself and I don't think
the UI is ever done untill the finished product is about to roll out.

Some current best practices I can recommend (these aren't easy)

I TRY to stay two weeks ahead of the current sprint (design wise,
prototyping, mock wise, usability testing) so you can have enough
time to act upon changes.

Communicate constantly with the team UI designer, coders etc..


Please followup after a sprint or two and let us know how the
practice you outlined is working. I would be curious to see how
features in your project are being ranked against usability concerns.


Side Note:
If you are unfamiliar with these terms check out http://
mountaingoatsoftware.com and several other sites. I also post some
information about agile http://www.uidesignguide.com


--- In agile-usability@yahoogroups.com, "Beth Meyer" <bethmeyer@...>
wrote:
>
> Hello, all;
>
> Well, I am very new to writing user stories, and my project team is
> not only new to agile methods in general but especially new to
> incorporating usability.  However, I found that when I tried to
> include usability criteria in the definition of Done (with a plan
> in place for getting rapid user input to validate those criteria),
> I got pushback from our resident agile expert because we can't
> estimate in the sprint planning meeting how long it will take us
> to reach the Done criterion.  If the results of having users bang
> on the first prototype are, "It's great!", then we're good - but if
> the results are that it needs some significant reworking, then our
> initial estimates for how long it will take to complete the story
> are blown out of the water.
>
> So, with regard to the features that really need some usability
> work*, my response was to have one of the Done criteria be that
user
> evaluation has been performed, but not that specific usability
> criteria had to be met for that iteration to be Done.  If we find
> issues in user evaluation that require significant reworking, we
can
> craft a user story around the specific problem that we found in
> testing for the next iteration.
>
> Do you see a major issue with that, and if so, how do your teams
> estimate the story points for a user story that specifies usability
> criteria that will be determined by user testing?
>
> *Note: Our project is a little unique in that we are upgrading an
> existing product that is OK usability-wise except for a few problem
> areas.  So we are not doing a wholesale rethinking of the UI.
>
> -Beth
>
>
> --- In agile-usability@yahoogroups.com, "imaginethepoet"
> <imaginethepoet@> wrote:
> >
> > I think you have look at the "done done" definition or acceptance
> > criteria and make sure your usability is included in the
> definition
> > of a stories aditional doneness. Of course,  users / customers
are
> > using the software throughout the sprint and examining the
> problems
> > with the interactions at that point.
> >
> > I would not separate out the usability aspect, but sometimes it
is
> > extremely difficulty to get usability as part of the acceptance
> > criterai. It depends on customer, company, etc... The end user
has
> to
> > be shown the business value to including the usability as part of
> the
> > done criteria. Sometimes this means getting buy-in from the BA /
> > Executive team. That makes this a very challenging process.
> >
> > I have found that when usability is "addressed" as a separate
> story
> > it tends to go ignored and is seen as unimportant to the overall
> > feature implementation. If you expereince this, the best advice I
> can
> > recommend is: Be loud and state the obvious.
> >
> > "Great our application has a ton of features can anyone use it?
> No?
> > Ok great than what was the point of putting this massive set of
> > features into the application?
> >
> > Don't be suprised if even that fails at some point. Next you
> should
> > desmonstrate in your (sprint review) or preferably thruogh the
> course
> > of the development of each story (especially as it's related to
> > Usability)the problems and pain points you see as a Interaction
> > Designer and get those things high on the priorty story back log!
> >
> > I actually talk a little bit about this in my blog.
> >
> >
> > --- In agile-usability@yahoogroups.com, William Pietri <william@>
> > wrote:
> > >
> > > Desilets, Alain wrote:
> > > > Not sure it makes sense to have usability as being separate
> from
> > the
> > > > user story.
> > > >
> > >
> > > I strongly agree with this.
> > >
> > > Each story is supposed to be a complete, releasable unit of
> work.
> > That
> > > doesn't mean it has every feature under the sun; often early
> > stories are
> > > very minimal. But it does mean that it should be 100% done.
> > Not "done
> > > except for testing." Not "done except for bug fixing."
Not "done
> > except
> > > for polish." When a story is declared done by the team, it
> should
> > be
> > > 100% done.
> > >
> > > If you are working in a context where usability matters, then
> that
> > 100%
> > > done should include making it well designed and meeting or
> > exceeding
> > > your usability goals. And for stories where usability is
> important,
> > > people who understand usability should be part of the
> conversation
> > from
> > > the beginning and all the way through.
> > >
> > > That doesn't mean that you can't schedule future stories whose
> > primary
> > > goal is improving the user experience. Sometimes you figure out
> > better
> > > ways only after a story has been in production a while.
> Sometimes
> > you
> > > intentionally defer usability improvements so that you can
> release
> > early
> > > and get feedback. Sometimes you want to ship out a relatively
> bare-
> > bones
> > > product for early adopters before you come back and make it
more
> > > approachable for other target audiences.
> > >
> > > Even then, though, it is important that be a conscious
decision,
> > with
> > > usability experts participating fully.
> > >
> > > William
> > >
> >
>

Would a headless system to an API really address usability? It seems
like taking the solid programmatic approach to a design issue only
caues usability issues. In many cases I've experienced the
programmers want and need to see something visually to build and
define the application.

I tend to think this may be helpfull on a case by case basis
especially when usability and (visual design) many times tie the
concepts of the interface into a cohesive unit.

Do you have some more examples to illustrate this? I find this type
of talk at the core of why I'm here.


--- In agile-usability@yahoogroups.com, "aacockburn" <acockburn@...>
wrote:
>
> I'm been following this question about usage and usability design
> VERSUS incremental development for quite a while - since Jeff
started
> up this group, and talking with him, and comparing how he describes
> visual designers' work v programmers work, and how I also do and
see
> them.
>
> I confess that I can't yet see a way out of the conundrum.
>
> Visual designers really do benefit from wide-band ideation,
exploring
> lots of ideas early and concurrently and leaving ideas on the table
for
> cross-pollination. The sketchboard and cartooning discussions show
this
> well.
>
> Software designers/programmers these days tend to get the base idea
> pretty quickly and program incrementally, changing the architecture
as
> they go.
>
> I don't know what the resolution can be. Certainly, faster more
sketchy
> ideation period for the visual designers, learn to adjust to
surprises
> that show up later and learn to work incrementally ... but until
and
> unless someone shows up with a way to revise UIs inexpensively half-
way
> through a project, I can't see advocating "do visual design as you
go"
> as some companies are forcing their visual designers to work.
>
> I will counter with a particular proposal that may buy visual
designers
> some time ... it's an idea from the old Smalltalk community back in
the
> early 90s. Namely - have the software designer/programmers design
and
> code up the system entirely to an API, not a visual interface.
>
> The API defines the services the system needs to support and the
> information structures it needs to be able to produce (and absorb).
>
> This is fairly much independent of the visual design, the sequence
of
> screens, the placement of visual elements. That design can be going
to
> in parallel, or even a bit behind, since it will simply call upon
the
> interfaces.
>
> As I wrote, this is what we recommended and occasionally did in the
> early 1990s on Smalltalk projects (using the transcript window for
all
> I/O to start with), and I have found myself doing this with my
current
> project to replace my website. We have the entire website working
with
> absolutely no visual design in place. There is (hopefully) nothing
the
> visual component will ask for that we haven't already tested that
the
> system can produce. We are, however, a bit more experienced in
talking
> about what the meaning of certain requests mean in terms of
> computational implication. We've recently started on the visual
design
> and not found any conflicts.
>
> what this means is that the software designer/programmers can code
and
> test every part of their work independently of the visual design.
>
> I don't know how this would look on a larger project with multiple
> teams.
>
> The hard part really is finding programmers who are willing to
build a
> headless system to an API. Most of them insist on a UI for no
> particular good reason (and thereafter couple the system too
closely to
> the UI and get stuck after that).
>
> If anyone else is / has played with this approach, please comment
on
> your experiences.
>
> cheers - Alistair
>

Hello, Jared.  On Thursday, May 8, 2008, at 5:41:36 PM, you wrote:

> My questions are this: In an agile project, *when* is time taken to
> initiate the vision? And, how does the team ensure, when the vision
> moves, that everyone "gets the memo"?

Consider XP Practices: Whole Team, Open Workspace, Team Code
Ownership ...

The team that lives together, sees together.

Ron Jeffries
www.XProgramming.com
Yesterday's code should be as good as we could make it yesterday.
The fact that we know more today, and are more capable today,
is good news about today, not bad news about yesterday.

Hello, leina.  On Thursday, May 8, 2008, at 5:49:06 PM, you wrote:

> What if the usability people wanted to dedicate an entire user story to doing
usability stuff.

> From where would they get the business value given that its not a
> straightforward process to be able to quantify the business value where
usability is concerned?

> Do you have any advice on working out the maths?

Customer determines stories based on (subjective) value. If they
want a usability story, they'll schedule it. If they don't, they
won't. Does that seem OK?

Ron Jeffries
www.XProgramming.com
Adapt, improvise, overcome.
   --Gunnery Sergeant Tom Highway (Heartbreak Ridge)

Hi, Susan. It sounds like we're on the same page. You made one point I
wanted to amplify:

meszaros_susan wrote:
> On the other end, when a story has been coded, we
> don't "close" the story until the tweaking is done. Big tweaks get a
> new story. This keeps the estimation realistic for the programmers.
>

I think that's exactly the right approach. Stories with stretchy
estimates can cause a lot of stress to all concerned. Honoring the
estimates also encourages positive behaviors like scope negotiation and
more thoughtful future estimates.

To decrease the need for tweaking, I encourage developers to work in
small units, so that they can show something to a product manager or
designer at least every few hours. Frequent small corrections minimize
end-of-story panic.

It's especially pleasing to me when designers and developers sit down
and pair on things. The faster the cycle of coding, showing, and
tweaking, the more waste you can squeeze out of the process.

William

The next APLN regional Leadership Summit will be held in Seattle on
July 17-18 at The Edgewater hotel on Elliott Bay in downtown Seattle.

[Sponsors to be announced]

Register now, http://www.apln.org/summits.html space is limited

We have a fantastic program lined up and a uniquely collaborative
conference format.

Key note speeches from

Lisa Haneberg,
author of several books including "High Impact Middle Management",
"Focus Like a Laser Beam" and "Two Weeks to a Breakthrough",

and John Yuzdepski,
Chief Marketing Officer at TestQuest, former VP & GM at Openwave and
prior to that VP & GM of Sprintpcs.com

a CIO panel - featuring leaders from firms around Seattle,
participants to be confirmed

Think Tank / Open Space Sessions led by recognized leaders in the
agile field, including...

Luke Hohmann, Collaboration Games
David Anderson & Corey Ladas, Kanban
Brent Barton & Lance Young (of Solutions IQ), Scrum
Mitch Lacey & Julie Chickering, Getting Started with Agile
Bruce Eckfeldt & Jim Benson, Writing Agile Contracts
Mike Griffiths, Agile Program Management
Chris Matts & Olav Maassen, Real Option Theory
Arlen Bankston & Jeff Patton, Agile User Experience

On Day 1 each Think Tank facilitator will lead an open space group to
develop new material, thinking and ideas. Participants are free to
choose a single session or wonder freely from session to session
learning and contributing to each.

On Day 2 each session facilitator will present a 20-30 summary of the
findings from the previous day. The output from all 8 sessions will be
made available to participants.

Please come and join us. Enjoy the beautiful venue. Enjoy the Seattle
summer weather. Enjoy mixing and networking with leaders in the agile
and board members of the APLN.

It's a mini-Agile Conference in the Northwest.

Enjoy the great food at the luxury Edgewater Hotel. Join us for the
cocktail reception in the evening of the 17th.

It's a fantastic package and all for the great price of $300 if you
sign up before June 18th. $400 after that date.

Register now, http://www.apln.org/summits.html space is limited

2008/5/8 Jared M. Spool <jspool@...>:

> My questions are this: In an agile project, *when* is time taken to initiate
> the vision?

I would contend that the vision should be initiated before a project
is started, whether working on an agile project or not, otherwise how
do you know where you are going?

> And, how does the team ensure, when the vision moves, that
> everyone "gets the memo"?

How would this happen on a non-agile project?

Jon Dickinson
http://www.accolade-consulting.co.uk

• Define UI cards (during Sprint 0), sometimes general, most of the time visual, to show the team the application posture, general usability and interaction design guidelines (VERY HIGH LEVEL) These cards, as classic user stories, are discussed with the team and users, and sometimes build during one or two workshops. It looks like the "constraints cards", described by Mike Cohn, in his book "user stories applied", but more visual. Sometimes, it's estimated by the team, sometimes not (integrated in the user stories)
• Associate usabilty doc (high level wireframes, storyboards) to user stories. In this context, my activity (usability / interaction design) is integrated in the estimation and planning of the user story for the iteration n. I integrate time for my review and exchanges with developement, but not for user testing which is sometimes a problem...

Hi, Susan. It sounds like we're on the same page. You made one point I
wanted to amplify:

meszaros_susan wrote:
> On the other end, when a story has been coded, we
> don't "close" the story until the tweaking is done. Big tweaks get a
> new story. This keeps the estimation realistic for the programmers.
>

I think that's exactly the right approach. Stories with stretchy
estimates can cause a lot of stress to all concerned. Honoring the
estimates also encourages positive behaviors like scope negotiation and
more thoughtful future estimates.

To decrease the need for tweaking, I encourage developers to work in
small units, so that they can show something to a product manager or
designer at least every few hours. Frequent small corrections minimize
end-of-story panic.

It's especially pleasing to me when designers and developers sit down
and pair on things. The faster the cycle of coding, showing, and
tweaking, the more waste you can squeeze out of the process.

William

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
>
> Hi, Susan. It sounds like we're on the same page. You made one point I
> wanted to amplify:
>
> meszaros_susan wrote:
> > On the other end, when a story has been coded, we
> > don't "close" the story until the tweaking is done. Big tweaks get a
> > new story. This keeps the estimation realistic for the programmers.
> >
>
> I think that's exactly the right approach. Stories with stretchy
> estimates can cause a lot of stress to all concerned. Honoring the
> estimates also encourages positive behaviors like scope negotiation and
> more thoughtful future estimates.
>
> To decrease the need for tweaking, I encourage developers to work in
> small units, so that they can show something to a product manager or
> designer at least every few hours. Frequent small corrections minimize
> end-of-story panic.
>
> It's especially pleasing to me when designers and developers sit down
> and pair on things. The faster the cycle of coding, showing, and
> tweaking, the more waste you can squeeze out of the process.

And reduce stress as you point out above. Working closely together
also results in mutual understanding and respect, and this works to
reduce programmer stress (oh, what are they going to come up with
next!!!). Our team has learned a lot about each others' disciplines
and as a result our communication has improved, and that means a
better result coming out of the project.

susan

>
> William
>

Looks pretty complicated to me...I don't understand the terminology
(without seriously considering and reading it), so why would the
customer understand?

I think you have to speak their language, and as William pointed out a
simple, quick and dirty calculation on the improvement in revenue due
to a small change as a result of usability improvements would
potentially scream "fix me fix me" to the cheque writers. Make it
meaningful to your target and they will not only understand but act.
Make them work to understand and you'll lose them (gee, isn't this
what happens with a bad interface or poor usability?)

susan

Austin Govella wrote:
> Agilistas claim you don't need vision: you'll figure
> it out when you get there.[...]
>
> In reality, the agilistas don't care if you communicate the vision.

Willam replied:

> They do? I'd love it if you could point me at your sources for that.

I think it's fair to say that *some* agilistas have that bias. But I'd say most
of the figureheads in Agile believe it's important to have a clear vision. Jim
Highsmith, Alistair Cockburn and Jeff Pattons (all prominent agilistas) are
names that come readily to mind.

Alain Désilets

Austin,

I have read the first three of those links and I don't see them as
saying that you can't or should not have a vision a priori. These
postings are talking about the day to day process of moving towards a
vision.

I wonder if we have different definitions of what a vision is. For me, a
vision is a 5 page document that describes what the business goals of
the project are, who the core users are, what their core tasks are,
etc... It can be put together in a week or two in a collaborative
workshop that brings together people representing different
stakeholders: business, end users, developers, marketing, etc...

What do you mean by a product vision?

Alain

> However, I've been researching this problem, and it's informed by
> writing from the agile community:
>
> Why You Won't Fix It Later:
> * http://on-agile.blogspot.com/2007/04/why-you-wont-fix-it-later.html
>
> Are we there yet:
> * http://www.scrumalliance.org/articles/37-are-we-there-yet
>
> Focus on value:
> * http://www.scrumalliance.org/articles/89-focus-on-value
>
> Kicking off the slow software movement (intro):
> * http://agileproductdesign.com/blog/slow_software.html
>
> Kicking off the slow software movement:
> * http://agileproductdesign.com/writing/slow_software.pdf
>
> Valuing outcomes over features:
> * http://www.artima.com/weblogs/viewpost.jsp?thread=183405
>
> Don't become an agile zombie:
> * http://outside-in-thinking.com/?p=93
>
> Don't know what I want, but I know how to get it:
> * http://agileproductdesign.com/blog/dont_know_what_i_want.html
>
>
>
> Is that what you were looking for? I think the clarification is that
> bad agilistas poo-poo vision. They also confuse the vision with the
> product.
>
>
>
> --
> Austin Govella
> Thinking & Making - http://www.thinkingandmaking.com
> Thinking Links - http://thinkingandmaking.com/links
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--- In agile-usability@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
>
> Hello, Jared.  On Thursday, May 8, 2008, at 5:41:36 PM, you wrote:
>
> > My questions are this: In an agile project, *when* is time
> > taken to initiate the vision? And, how does the team ensure,
> > when the vision moves, that everyone "gets the memo"?

In Industrial XP, there is a Chartering activity. In Crystal Clear
there is the "Mission statement with trade-off priorities" work
product. In Jim Highsmith's writings there is something similar (but
I don't recall the name).

From the Crystal Clear book:

Sponsor (produces): Mission Statement with Trade-off Priorities

The mission statement is a brief description, typically a paragraph
to a page, of what is to be built, its purpose in a larger context,
and the project's priorities in sequence, from the most critical to
those that can be sacrificed.

It is produced by the sponsor, before the project starts or during
project chartering. It is reviewed by the business expert and lead
designer, and referenced by everyone on the team. Any major change in
the mission statement triggers a team meeting, so that everyone one
the team understands the new mission.

A good mission statement retains its clarity and relevance over time,
keeping the work efforts focused on the most important features of
the system.

Because people can generally only protect one and possibly two
project priorities, it has no more than two top priority items. The
priorities might be chosen from hitting a particular delivery date,
cost, ease of use, ease of learning, speed in use, correctness,
performance, ease of maintenance, design flexibility, legal liability
protection (you may come up with other choices for your project). The
mission statement makes clear to the team what can be sacrificed if
necessary to preserve the top priorities.

--- In agile-usability@yahoogroups.com, "imaginethepoet"
<imaginethepoet@...> wrote:
> As to including your "UI" in the definition of done. This
> can cause problems. I'm still working through this one
> myself and I don't think the UI is ever done untill
> the finished product is about to roll out.

My son just bought Civilization 4, and it comes with a video of the
lead designers talking about how they developed it over a 3-4 year
period.

Just as you write, he says essentially the same thing.

For cost reasons, they built a working game with simple graphics in
the first 3 MONTHS, and deferred detailed graphics until the last 1/3
of the project (when they had many artists working on detailed
graphics).

The talk is fascinating from many perspectives, analyzing what they
did early, what they deferred, where they were obliged to backtrack
(having to simplify the graphics was the biggest surprise to me),
etc.

If you can get hold of this talk (they gave it at some gaming
conference also), it's well worth watching two or three times to get
some deeper sense of how their approach addresses discussions in this
thread.

Alistair