[rt-users] RT to support software development teams when using Agile / SCRUM approaches to planning work

[Ken Crocker]

Rudiger,


    Sorry for the delay. I've been up to my *&^%$% in alligators so I've 
been delayed in draining the swamp.
    What you state IS workable. We do not move the finished "Stories" to 
a review queue, we just added a Ticket Status" of QA testing. We run our 
queries accordingly and review the "QA" results of the stories in that 
status.
    The answer to your question as to navigating to/from child tickets 
in the Web is YES. However, I think that the 3.8.2 makes it MUCH easier 
to create them.
    The rolling up of child data (like time) into the parent is 
something you could do, but you would have to create your own cron job 
to do that. I haven't seen anything like that in delivered RT.
    Hope this helps.


Kenn
LBNL

On 3/19/2009 3:07 PM, Rüdiger Wolf wrote:
> Ok Thanks for your feedback.
>
> Scrum in 5 minutes
> http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
>
> Based on what you say it seems like the following might work.
>
> Each project/team has a BACKLOG QUEUE of stories(requirements). The
> product owner regularly prioritizes them.
> During the fortnightly planning meeting the product owner selects some
> stories from the BACKLOG and moves them to the CURRENT SPRINT QUEUE
> prioritizing them as he/she does so.
> Team members select stories from the CURRENT SPRINT QUEUE and add child
> tasks.
> When all the tasks are done for a particular story, the story is moved
> to a REVIEW QUEUE.
> During the sprint review meeting the product owner reviews the features
> related to stories in the REVIEW QUEUE and stories are marked as done.
>
> Is it possible to roll up child data into a parent?
> The question might be how many hours of work are remaining for this
> story?
> Hours work for a story(parent) = sum of remaining work estimate for all
> its tasks(child).
>
> Is it easy to create child tasks? And navigate through them via the web
> interface?
>
> Thanks
> Rudiger
>
>
> On Thu, 19 Mar 2009 12:10 -0700, "Ken Crocker" <kfcrocker at lbl.gov>
> wrote:
>   
>> Rudiger,
>>
>>
>>     I'm not sure what you mean when you refer to "SCRUM". However, we 
>> ARE supporting many software applications with technical support teams 
>> and Queues oriented for each application/team. We have 1 queue 
>> specifically designed to act as the initial request Queue where tickets 
>> are reviewed and prioritized, then (if approved) moved to the queue that 
>> supports the application the ticket is asking work for. For example, one 
>> large support group, Financial, supports all the various software 
>> dealing with our financial organizations and they have 12 different 
>> queues for that activity. There are, consequently at least 24 different 
>> groups,  where each queue has a user group that WORKS on the tickets and 
>> another that is allowed to CREATE tickets (some that have the same 
>> members).  Our structure for privileges is rather tight (only a couple 
>> for "Priviliged" Users. Mostly Queue-oriented)) that allow for keeping 
>> tickets secure (only the OWNER and the Queue Manager can Modify a 
>> Ticket) within their queue. We also have a QA Workflow process that 
>> ensures our standard for QA Approval is followed before a ticket is 
>> allowed to be "QA Approved" and then Resolved (for example, we NEVER 
>> allow the ticket owner to QA Approve their own work). A separate user 
>> from the QA Approval group are the only ones with privileges to modify 
>> the CF that is used to indicate QA Approval.
>>     Anyway, that's pretty much a summary of how we do things. If the 
>> details of any of this will help you, then I'd be glad to share how we 
>> do it.
>>
>> Kenn
>> LBNL
>>
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20090320/2868edf2/attachment.htm>