Re: [scrumdevelopment] Iterations and business value delivered
- | in addition to what the others said (and will say) I think
|you should work more with the PO. Usually a full login feature is far
|from being the highest priority/value one, or is you system supposed
|to deliver value letting people login and do nothing else? ;-)
Sometimes that is indeed what you want. This could indicate that there
are some sort of third party interests involved and as a prerequisit to
further funding the Login has to work by XY. Thus the login becomes the
most important functionality.
But as I said that might be rare :)
- As may have already been pointed out, the customer is probably confounding business dependency for business value. Just because in the final delivery, a user has to log in before he can do anything else, that does not mean logging in the most valuable thing the system provides. I sometimes first ask the customer for the most core functionality instead of the most valuable.
I also suspect two possible explanations for a login implementation to be too complex for a team to do in the first sprint:
1. All sorts of startup tasks (setting up machines, source control, databases, development environments, build scripts, etc.) are taking up much of the available time.
2. Authorization is being confounded with authenication.
If the first is the case, ask the customer to pick something smaller and more core to allow the team time to set up their infrastructure and still deliver something.
If the second is the case, write and estimate separate stories about deciding what a user is permitted to do after logging in. The implementation of those stories may later change some of the guts of what happens when a user logs in, but those changes should not be rewrites if proper OO principles are followed.
Steven GordonOn 9/2/06, mi97ki <mi97ki@...> wrote:
the organization I work for has decided to adopt Scrum on one
We are just starting and we do not have a mentor so we are facing
One is the following. We went through the planning meeting for the
first iteration. During the meeting the Product Owner indicated that
specific feature had the highest priority. Now it does not seem that
can break down this feature in many small user stories. After all
end user is required to do very little to log on to the system:
username and password and click an OK button. That's it. On the
hand, the infrastructure required to log on to the system turns out
be quite complex (it's an enterprise application). 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.
if we add the user story "Logging on to the System" to Iteration 1,
won't be able to finish it in time (according to the estimates) //if
implement the entire back-end to support real authentication//. On
other hand, if we decided to mock some part of the back-end in order
meet the deadline for the iteration, we feel that we will not
any business value.
What should we do in this case or, more in general, what should we
anytime we have to implement a feature that has a small number of
stories associated and a big backend?
I am sure we are missing something. Any suggestions would be
P.S. This message was posted also on comp.object. Here's the thread:
- This is actually one of the examples I use when I teach teams how to
break down features into stories that can be iterated. This method
works if you are not releasing to the customers after each iteration.
An example of this would be that in your first iteration you would
have the focus on creating a screen with the login fields that fits
your standard "look and feel" User Experience criteria. The fields
can accept characters, but there is no backend.
The second iteration could include the ability for there to be a
file that can accept the user names and passwords with
authentication to that file.
The third iteration could include a story to extend the validation
to be able to use LDAP or other commonly used variations.
The fourth iteration could include roles or user types so that only
the appropriate menu items are displayed when a user of that role
And so on.
This way you can meet the acceptance criteria for each iteration and
close the iterations with accepted stories. You can still have
regulated iterations of standard lengths and keep the customer's
needs the focus of each iteration.
- (responding to leknudsen, all)> This is actually one of the examples I use when I> teach teams how to break down features into stories> that can be iterated. This method works if you are> not releasing to the customers after each iteration.Of course, there are ways to release to the customernevertheless. We get good feedback and somebusiness value if we release to the customers fortest and familiarisation, pointing at a test database.We get real business value if the product is releasedto a restricted set of customer users who are trustedto work unauthenticated and fully authorised. It maybe the case that we can give 2 releases and do bothof the above at the same time.At the risk of pointing out the obvious, because of thesesorts of possibilities, we should be clear about exactlywhat we are delivering at the end of an iteration so thecustomer can prepare to use it effectively. And to tiein with other recent threads, this latter topic is a goodreason to make great effort to meet our commitmentsand not to add extra user stories during an iteration.Paul Oldfield
- Hello leknudsen_2000, thank you for the thoughts quoted here. I'll
be offering a different angle. On Monday, September 4, 2006, at
1:55:20 AM, you wrote:
> This is actually one of the examples I use when I teach teams how to[descriptions below trimmed by me]
> break down features into stories that can be iterated. This method
> works if you are not releasing to the customers after each iteration.
> first iteration ... a screen with login fields, no backend.If the entire project was just to implement the ability to log in,
> second iteration ... a file, user names, passwords,
> third iteration ... extend the validation, LDAP or other
> fourth iteration ... roles, user types, only appropriate items
> displayed when a user-role logs in.
> And so on.
> This way you can meet the acceptance criteria for each iteration and
> close the iterations with accepted stories. You can still have
> regulated iterations of standard lengths and keep the customer's
> needs the focus of each iteration.
this would be a good example of how to do it in iterations that
would make sense to the customer.
As others have pointed out, if the point of the project is really
that when someone finally gets logged in, they press a button and
something big happens, I would start with breaking down the
something big and making it happen. If I had a screen at all, it
would just have a button on it. More likely, no screens at all.
Presumably the business value comes from the something big, and
therefore it should be done first.
Knowledge must come through action;
you can have no test which is not fanciful, save by trial. -- Sophocles
- You are presuming something that the original writer did not state. He stated the the Product Owner listed the login screen as highest priority. He didn't state the risk assigned to the entire backlog, but did indicate that this was primary on the product owners' list.Of course the product would need more in it than simply to log on. I was not implying that the login would be the only feature of the product. I would hope there would be enough people assigned to this project that the next highest priority item could also be started during these same iterations. Do you only work on one feature at a time? One story? What sort of project allows this and yet still delivers value at each iteration?My example was simply to show how you can break down larger requirements into manageable chunks. Which I thought was the question being asked.