Re: Iterations and business value delivered

Op 1 Sep 2006 12:34:22 -0700 schreef "Max" <mi97ki@xxxxxxxxx>:

Max,


Hi,

the organization I work for has decided to adopt Scrum on one project.
We are just starting and we do not have a mentor so we are facing some
challenges.

One is the following. We went through the planning meeting for the
first iteration. During the meeting the Product Owner indicated that a
specific feature had the highest priority. Now it does not seem that we
can break down this feature in many small user stories. After all the
end user is required to do very little to log on to the system: provide
username and password and click an OK button. That's it. On the other
hand, the infrastructure required to log on to the system turns out to
be quite complex (it's an enterprise application).


I have two comments on what you say here:

1) The model of the problem:

Use case analysis of a system will *not* reveal a use case "log on"
nowwhere, never. A use case should provide independent value to one of
the actors. Logging on to a system will not do that. Logon is more
like a (trivial) step in a lot of use cases. If you dont have a use
case logon, no product owner can set a priority to it. This is quit a
standard problem which you face here....."your use case is to small
and provides no independent value".


2) The model of the solution:

The "infrastructure " to logon to a system is trivial since this
problem is solved a million times already. Consider using AD for
instance, or any other authentication framework. No doubt there will
be difficult implementation details as to which organizational
units,groups and policies to use, but still this step in the use case
is trivial considering the value that your "to be designed use case 1"
will give to the entreprise.


So here's the
problem we are facing as a Team: we know that at the end of each
iteration we have to provide a production-quality increment.

You can't because you dont have a qualifying use case. Go back to
problem analysis.

However,
if we add the user story "Logging on to the System" to Iteration 1, we
won't be able to finish it in time (according to the estimates) //if we
implement the entire back-end to support real authentication//. On the
other hand, if we decided to mock some part of the back-end in order to
meet the deadline for the iteration, we feel that we will not generate
any business value.


You will not generate any business value anyhow by implementing logon.
Make a mock up, and put developing ( or rather adopting) an
authentication framework as a parallel development proces. It quit a
good candidate for independent reusable component for a component
developer. Put the majority of the application developers on the "to
be developed use case" and let them use the mockup that is the
component developer's first task.

What should we do in this case or, more in general, what should we do
anytime we have to implement a feature that has a small number of user
stories associated and a big backend?


Go back immidiately.

I am sure we are missing something. Any suggestions would be
appreciated.


You are missing the point about use cases. Use case analysis is not
functional decomposition. This mistake is so generic that I cant blame
anyone for cloning this misconception. The axe of problem and the axe
of the solution are best understood as orthogonal. The problem wants
value, the solution wants reuse over values.

Rick
.

Quantcast