RE: Question_Agile Process_ UIE Virtual Seminar

I use the same terms and the same words (sans buy) to do something a bit
different.

All stories accepted into a sprint/iteration must be completed within that
sprint.  Completed requires they have associated with them a traceablity to
the value proposition the product owner can sign up with.  Completed occurs
when the measurable indicators associated with that story are met.  So
William's muddle is taken and decomposed as the inability of the Product
owner to identify measurable for the value of a story provide the shoice
criteria for a story be tgaken into an iteration.

 

I also have a problem with the notion there is a 'project backlog'  this
assumes that all stories are associated with a single project.  In the world
that I work in as many as 17 teams have been working on a dozen projects all
under the umbrella of a very large program.  I can understand how a UI
perception of work would see this scale and scope as the future of UI is the
challenged with providing a user a common experience through an endless
variety of devices and interfaces so that the way a user gets what they want
has to be consistent despite the different capabilities and limitations of
the vehicle used.

 

We have already faced the challenge of the limit of thinking in project
terms and offer this learning.  There is a product backlog where stories are
kept and as the story's value is understood, the story is moved into
releases where it eventually ends up being delivered in such a way  as to be
valuable to the user

 

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   (978) 376-4422

email: mdwyer@... <mailto:asingh@...>

 

 

From: Srinivas Manda [mailto:laksinu@...]
Sent: Monday, March 09, 2009 8:58 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

Thanks Mike ....

 

in a project we usually take all the features and build them in the form of
" user stories"  and place all of these stories in the project backlog and
we as a team take some of the stories  and buy them in each iteration.

 

example : -

 

say in total we have around 20 stories in the product backlog

say we have 4 iterations

 

5 stories x 4 iterations = 20 stories
and the entire project (20 stories that are in the backlog) can be done in 4
iterations ....

 

each iteration has 5  stories that team buys based on the priority  that is
what i mean
by "buy stories"..

 

 

let me know if you have questions ....

 

-srinivas

 

----------------------------------------------------------------------------
------

 

 

----- Original Message -----

From: Mike Dwyer <mailto:mdwyer@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 6:40 PM

Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

What do you mean when you say 'buy stories'.  I am unfamiliar with that
term.  It sounds like you have a supplier vendor relationship instead of a
collaborative one.

From what little I understand it seems you are attempting to retain a wall
between the developers, designers and the users.  If I may suggest, you
might find it interesting to think about beginning with defining everything
according to its value, which I take to be usability as it is the only item
worthy of testing.  However, by expanding the notion to value the customer
can now define the comparative worth of stuff they use based on its value to
them in getting the job at hand done.  This would expand the interaction of
all by merging their contributions to the customer value needs and thus
create a more complete test of usefulness.

Just a thought

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   (978) 376-4422

email: mdwyer@... <mailto:asingh@...>

From: Srinivas Manda [mailto:laksinu@...]
Sent: Monday, March 09, 2009 7:03 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

Thanks William, the problem is in Agile you know that we always buy stories
and work on them in sprints ...
designers always do early designs so that it can be usability tested before
developers actually code it ....

in  iteration zero if designers work on the features that time developers
might buy some stories (technical) and they are busy with it...

1. Put everybody in the same room.
if developers are working on other stories how can they be part of design
stories
2. When designers design, encourage them to frequently get feedback
from the developers.
developers are busy with other stories how can they contribute of the
stories that designers might have bought
3. When developers develop, encourage them to frequently get feedback
from the designers.

-laksinu

----- Original Message -----

From: William Pietri <mailto:william@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 4:38 PM

Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

Srinivas Manda wrote:

(in Iteration ZERO developers may not be ready to participate with designer
as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements / Screens
/ Spec of the First feature to the developers so that they can code it..
and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?



My easy three-step solution:

1. Put everybody in the same room.
2. When designers design, encourage them to frequently get feedback
from the developers.
3. When developers develop, encourage them to frequently get feedback
from the designers.


I've seen this approach work well for quite a number of successful teams. It
turns out people are never too busy to talk with the guy sitting right next
to them, especially when it makes both of their jobs easier.

William

--
William Pietri - william@... - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
We'd love feedback on our new blog: http://agilefocus.com/