Topic
  • 9 replies
  • Latest Post - ‏2009-02-27T20:49:56Z by SystemAdmin
SystemAdmin
SystemAdmin
3545 Posts

Pinned topic Elaboration and Building Scenarios

‏2009-02-26T15:52:51Z |
Hi everyone,

I have a question concerning Elaboration and building full scenario and testing.

In Elaboration should you build a full scenario including the user interface (let say the basic flow of a specific use case) to mitigate one or more technical risks and/or prove your architecture. Or should you only build the specific parts of a scenarios to mitigate technical risk?

Currently we chose to only build a part of a scenario to mitigate a technical risk, but by doing so it's hard to test and we don't really have a working software at the end of the iteration since we only build a part of the scenario.

Please advise

Thanks
Updated on 2009-02-27T20:49:56Z at 2009-02-27T20:49:56Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-26T16:29:22Z  
    Martin -

    It depends, but I would say "Yes" implement the complete scenario. This way your iteration is delivering more value that could be potentially reviewed with your stakeholders for feedback.

    If testing is an issue, try writing the tests first to help drive your development.

    Carson
  • Mark.Lines
    Mark.Lines
    56 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-26T21:51:34Z  
    Hi Martin,

    I agree with Carson. Each scenario that you build should be working, tested, demonstrable software.

    That is not to say that you necessarily finish it (all defects tested, and no changes required). You can certainly enhance or fix scenarios built in previous iterations.

    One of the goals of building this way is, as a PM, to get metrics on the team's productivity for developing flows (pieces of scenarios) of relative sizes. This gives us information to extrapolate estimates for time remaining at the end of Elaboration. This is also known as team "velocity" in the agile world. It is therefore important that each scenario be taken to a certain level of "doneness" for comparison purposes.

    Mark

    Mark Lines
    RUP Discussion Facilitator
    Founding Member of IBM Rational Methods Customer Advocacy Group
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T14:30:42Z  
    Hi Martin,

    I agree with Carson. Each scenario that you build should be working, tested, demonstrable software.

    That is not to say that you necessarily finish it (all defects tested, and no changes required). You can certainly enhance or fix scenarios built in previous iterations.

    One of the goals of building this way is, as a PM, to get metrics on the team's productivity for developing flows (pieces of scenarios) of relative sizes. This gives us information to extrapolate estimates for time remaining at the end of Elaboration. This is also known as team "velocity" in the agile world. It is therefore important that each scenario be taken to a certain level of "doneness" for comparison purposes.

    Mark

    Mark Lines
    RUP Discussion Facilitator
    Founding Member of IBM Rational Methods Customer Advocacy Group
    Does this means we should assign points to scenarios only. Because right now we assign points to each work items and not for the scenarios.
  • Mark.Lines
    Mark.Lines
    56 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T15:51:56Z  
    Does this means we should assign points to scenarios only. Because right now we assign points to each work items and not for the scenarios.
    A Work Item could be a Scenario. However I break scenarios into their flows for the purpose of estimating with points.

    Mark
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T16:08:15Z  
    A Work Item could be a Scenario. However I break scenarios into their flows for the purpose of estimating with points.

    Mark
    Ok for me a scenario and a flow are the same thing, I'm I wrong here? For example for me the number of scenarios (flows) in a use case is the number of alternate flows + the basic flow. So if a use case has 10 alternate flows than this use case has 11 scenarios.

    As for our work items, they are pretty much detailed, for example: Building Class ABC, Unit Tests for Class ABC, Create Database Table XYZ. And all these detailed work items are assigned points and put into an iteration. We also add the scenarios as work items, but we link the scenarios work items to their corresponding detailed work items.

    Maybe we are doing this the wrong way and over doing it? Should we only assign points to our scenario work items?

    Thanks

    Martin
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T16:10:33Z  
    A Work Item could be a Scenario. However I break scenarios into their flows for the purpose of estimating with points.

    Mark
    I agree with Mark. Generally estimation by assigning points is done by the whole team either at a user story, use case, or scenario level. (I like to think of a scenario as one discreet flow within a use case).

    I guess you could break down the estimates further into work items such as: solicit requirements, analyze requirements, design, implement, test, etc.. but those types of granular estimates may be misleading when there are still many unknowns. Check out planning poker and the reasons why to use a fibonacci scale when doing estimation.

    Carson
  • Mark.Lines
    Mark.Lines
    56 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T16:21:21Z  
    Ok for me a scenario and a flow are the same thing, I'm I wrong here? For example for me the number of scenarios (flows) in a use case is the number of alternate flows + the basic flow. So if a use case has 10 alternate flows than this use case has 11 scenarios.

    As for our work items, they are pretty much detailed, for example: Building Class ABC, Unit Tests for Class ABC, Create Database Table XYZ. And all these detailed work items are assigned points and put into an iteration. We also add the scenarios as work items, but we link the scenarios work items to their corresponding detailed work items.

    Maybe we are doing this the wrong way and over doing it? Should we only assign points to our scenario work items?

    Thanks

    Martin
    Scenarios are merely compositions of flows (Basic + Alternative, as you said). We select a set of scenarios to build in a particular iteration. Because basic & altenative flows appear in multiple scenarios potentially, we need to estimate at the flow level (to avoid double estimating)

    Regarding your work item list, the granularity of work items is a matter of style, but I believe that your work items are too low level. You need to decompose your work items into tasks that team members identify and estimate for (a la 'self-organizing' teams). The estimates at this level are in real values (eg hours), rather than the point estimating that occurs when estimating for your work item list.

    Unified Process Mentors (www.UPMentors.com) teaches a 1 day course on running an agile iteration with UP. We show how to do this estimating and create a work item list.

    Hope this helps.

    Mark
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T16:26:10Z  
    Ok for me a scenario and a flow are the same thing, I'm I wrong here? For example for me the number of scenarios (flows) in a use case is the number of alternate flows + the basic flow. So if a use case has 10 alternate flows than this use case has 11 scenarios.

    As for our work items, they are pretty much detailed, for example: Building Class ABC, Unit Tests for Class ABC, Create Database Table XYZ. And all these detailed work items are assigned points and put into an iteration. We also add the scenarios as work items, but we link the scenarios work items to their corresponding detailed work items.

    Maybe we are doing this the wrong way and over doing it? Should we only assign points to our scenario work items?

    Thanks

    Martin
    Martin -

    Iteration planning at that granular of a level, e.g. class, table, etc.. may be useful but borders on diminishing returns during an agile project. Generally, design and implementation items such as classes and DB tables are not yet realized during scenario estimation. I would keep estimation at a higher level.

    Carson
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Elaboration and Building Scenarios

    ‏2009-02-27T20:49:56Z  
    Martin -

    Iteration planning at that granular of a level, e.g. class, table, etc.. may be useful but borders on diminishing returns during an agile project. Generally, design and implementation items such as classes and DB tables are not yet realized during scenario estimation. I would keep estimation at a higher level.

    Carson
    Thanks guys this really helps