Estimating time and assigning scenarios...

Estimating time and assigning scenarios...

• Zappo

  Wow - what a great set of posts! I love these discussions. The original questions were:
  1- Isn't a scenario always broken down into one or more tasks for developers to impelement
  -> Yes, although trivial scenarios that involve a single developer can just be assigned.
  2- If the above statement is true, then why do we assign scenarios to individuals Why do we assign scenarios to anyone at all, since implementing the scenario would actually mean implementing each of its individual tasks
  ->Ahhh - great question. The scenario starts out (in active state) assigned to the business analyst, the person who writes it. As soon as it becomes part of the iteration plan, it gets assigned to a developer. If you wish, you can think of them like a development lead who makes sure that all of the pieces of the scenario are integrated and working. When the scenario is complete, the developer assigns the scenario to a tester. The scenario is in the "resolved" state. This is an indication that the scenario is in the build. If an automated test case can be attached to "prove" that it works - great! The tester closes the scenario when all of the tests run unblocked (but bugs are fine). If you look at the remaining work report (at the bottom), the reason for this becomes clear.
  3- Is it correct to estimate a time for a whole scenario Shouldn't we actually estimate the time for each task requried to be done to acomplish this scenario
  ->Yes, the ROM (rough order of magnitude estimate) was originally based on the entire scenario. We have changed this in RTM to a technical complexity measure based on a scale from zero to three. Three is too hard and should broken into smaller pieces. Zero is trivial. One is low and two is medium complexity. Beta 3 users will find days in this field.
  4- Isn't a scenario just another name for a use case (with alternative courses, exceptions and all) or am I confused
  -> A scenario is a piece of a use case as was mentioned in this stream. We use scenarios because they provide finer granularity (a use case is lot to bite off in a single iteration). If you are interested in use case modeling, you can read my earlier book Advanced Use Case Modeling.

  Randy
  MSF
  
  http://www.microsoft.com/msf
  http://www.advancedusecases.com

  
  
  

• Stephan Ruhland

  The scenario starts out (in active state) assigned to the business analyst, the person who writes it. As soon as it becomes part of the iteration plan, it gets assigned to a developer.
  
  I see so when a scenario gets assigned for the first time, it's actually not written yet, it's assigned to someone who will write it in the first place. As I'm understanding, after he writes it, he first makes it a part of an interation plan then assigns it to a lead developer. Now what does that developer do, implement it, break it up into tasks or do either depending upon the complexity of the scenario Or maybe none of the above altogether (as in, the business analyst who writes the scenario is the one that actually breaks it up into tasks in the first place before assigning it to developers )
  
  We have changed this in RTM to a technical complexity measure based on a scale from zero to three.
  
  So now how can we estimate the iteration plan time
  
  BTW the part in the process guidance that explains how to set up an initial and a first iteration plan in Microsoft Project is (in my own opinion of course) a little confusing. Here's what I understood so please correct me if I'm wrong:
  
  1- Iteration 0 is the first iteration plan, and it consists of the tasks that are assigned automatically to the project creator (basically the Project Checklist tasks).
  
  2- The real project actually starts at Iteration 1 (referred to as the Initial Iteration in the process guidance) which is only defined after the scenario list is written (and the time for each scenario determined I guess not since you said you're changing this in the RTM version). Iteration 1 would consist of a subset of this scenario list. But then again I fail to understand how an estimation of time for this Iteration is determined from this.
  
  Thank you and sorry if my questions don't make sense, since I'm a bit confused for some reason. I wish there was a book about the whole process.
  
  Sammy
  
  

• Adrigo Gallus

  Don't feel alone, I'm lost on the answer to these questions as well. If only there were a book for MSF 4.0.....
  
  

• kawano1h

  If I think a scenario is large and difficult, I would split it to be more confident with the work that involves.
  A scenario like the one you are describing is very common in many applications, so if it is not the first time you work on a Sign in scenario, you would be able to estimate it accurately.
  In the other hand, it depends very much on the size of your project and team. You have to consider, if it is a small project/team, if it is worth spending time splitting a scenario into very granular tasks. In some cases a senario could be split in tasks such as "implement sign in", "implement stored procedures for sign in", etc...
  
  

• jw700

  "Since I think that it is not necessary to broke down each scenario completely in tasks, it would be better to estimate the time for the whole scenario."
  
  Isn't this pretty difficult to do ! If I have a scenario titled "Sign In" that involves the user entering an ID/password that get submitted to a server for authentication and then return a token that gets stored in a local database for instance; how long do you think that would take to complete ! I can't for the life of me give a correct estimate for such a complex task since it involves writing code in more than one component.
  
  Also, from what I understand, you're telling me that developers can directly implement "scenario" work items. Did I understand correctly
  
  By the way I'm downloading the evaluation version of Enterprise Architect; it does look very promising; thank you for pointing it out.
  
  I appreciate your help, I feel a little lost for some reason
  
  Thank you,
  Sammy
  
  

• kiranv

  Hi Sammy,
  This is my own appreciation to your questions, since sometime ago, I had similar doubts and had to think about...
  
  1. I understand that, as you say, a scenario could be broken down in tasks. However, I think that it is not necessary to describe the whole scenario in tasks. The asignation of a scen.ario to a developer is already considered an assignament of work to do. Then, it depends on the scenario, you can asign further tasks related to that scenario, that may require attention or further clarifitation. But the tasks you assign related to a scenario are not necessary to refer to the whole of it.
  2. read 1.
  3. Since I think that it is not necessary to broke down each scenario completely in tasks, it would be better to estimate the time for the whole scenario. However, if you have already split it in tasks, that must match most of it. But don't forget that you also have to consider time for testing the scenario.
  4. I found out in a UML modeling program named Enterprise Architect (EXCELLENT - A MUST HAVE) that when you create a use case, then you have the chance to broke it down in different scenarios. So, if you have a use case named "Manage customers", the scenarios that compose it would be "Add customer", "Edit customer", "Delete customer", "View customers". My opinion is that if you work with scenarios, you will have more items than in a use case based approach.
  
  Well, as I mentioned first, this is my appreciation. I am almost convinced of that!
  
  
  
• Estimating time and assigning scenarios...