Case study on agile planning sessions

[Barbara Glover]

Hi Daphne
My understanding of how Toronto does the time estimates is as follows:
- each activity is listed on the board and who is going to work on it.
- that person/people makes an estimate as to how many "ideal" days it  
would take to complete (can also be less than 1 day)
- this is written on the board in say red
- at the end of each day, the person if they worked on that item,  
marks in say blue, how much time they spent.
- if an item is completed then an checkmark is placed beside it.
- at the end of the iteration, for each item the team can see how  
long they estimated vs. how long it took to complete.


-barbara

On 11-Oct-07, at 3:39 PM, Daphne Ogle wrote:

> Hi all,
>
> I promised to send out a case study on agile planning sessions to  
> help us gain common ground and make the conversation more  
> concrete.  Check out, "The Nature of the Team" under the Resources  
> section at http://wiki.fluidproject.org/x/SwMa.  Planning sessions  
> are specifically discussed on:
>
> - pg 12, "Interactive Planning Sessions"
> - pg 18, "The Project Plan"
>
> Reading the entire document will help put the planning sessions in  
> context.  As we talked about at the meeting, our goal for this  
> process is to gain transparency into the work and status as it's  
> happening, enable regular conversations about priority, resource  
> needs and evolving state of our knowledge and how that effects the  
> roadmap.   The wiki page referenced above describes the goals and  
> plan in more detail.
>
> Some questions to ponder before next week's meeting:
>
> -  Are there applications that can help us replicate the  
> interactive moving around of story cards in our distributed world?
> -  Do we need a coach?  If so, who interested?  Although we've  
> talked about taking a lightweight approach, there will still be  
> coordination and management overhead to collect and organize story  
> cards and run the meetings.
> -  What is the right level of granularity for our story cards?  My  
> experience has been that they are pretty granular for near term  
> activities and they get more abstract the further out they are in  
> the plan (makes sense not to spend a lot of time on describing  
> longer term activities since things change as we learn more and  
> adapt).   Seems like we want to be granular enough to define  
> realistic estimates but we'll all be working with different  
> processes and methods depending on the project team so a certain  
> amount of detail is probably unrealistic.
> -  What is your estimated time commitment to Fluid UX activities?   
> We'll need to have some realistic total number of hours available  
> in order to slot cards into the time for each iteration.  The time  
> we each have will likely change across time depending on other work  
> and local priorities; but we should come up with a starting point.
> -  What's the right length for an iteration?  We talked having  
> monthly planning sessions and thus iterations.
> -  What's the best way to do estimating?  My experience has been  
> that each team member gives an estimate for a particular activity  
> based on that individual doing the work and then an average is used  
> for planning.  In that case, we didn't know who would be assigned  
> to each activity at the point of estimating so it made sense to  
> take an average.  We may have more information about who will be  
> working on particular activities.  How does Toronto handle estimates?
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (510)847-0308
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071011/1ec25b44/attachment.html>