Time keeping?

Scrum for Team System - v1.x Support

Time keeping?

mikehibbert 04-28-2006, 12:24 PM

I'm just getting my head around using scrum for team system, and can't see how to get actual worked time into the system.

Do you have any recommendations for time keeping in scrum for team system?

I expect the team to update their actuals against work items each day, ideally more than once.

Can we do that in scrum for team system?

Re: Time keeping?

DBreggin 04-28-2006, 7:03 PM

One of the philosophies of SCRUM is that how much work you have done is irrelevant to meeting the sprint goals. Knowing you have done 5 hours of work is not important, what is important is knowing you have 10 hours left. In my experience, it is not uncommon to start with an estimate of 8 hours, and after 5 hours of work still have 10 hours (not 3 hours) to go. The actual scope of the work becomes more visible to the person doing the work as the work progresses. This was one of the real 'ah-ha' points of Scrum management for me.

So, have the team keep their remaining work updated (this is a better predictor of when you'll be ready to deliver).

The important factors are team capacity remaining and estimated work remaining as related in the sprint burndown chart. Make sure the burndown line approaches 0 work left to go @ 0 time left to go. Above this line, and its time to reduce scope, below this line, and it 'may' be time to add to the scope.

If you absolutely have to track work done for project billing, it is pretty easy if everything in the sprint is for a single project. Otherwise, you should have multiple sprint team assignments to separate the projects. At the end of each sprint, in the sprint retrospective, you should always bring up estimation lessons learned to be applied to future sprint planning. At first every team I have worked with over-estimates, and after a few months starts to get it really right.

I hope that helps...

Dan

Re: Time keeping?

mikehibbert 05-17-2006, 11:23 AM

Hi Dan, sorry I managed to miss your response for a few weeks.

I have worked out an efficient way to capture actuals now.

However what you say seems like an 'ah-ha' leap I'm still not quite getting. Do we not need to capture actuals at all?

I anticipate invoicing the team's time weekly... showing actuals against agreed product backlog items selected for the current iteration. So each week the customer will see how much they have invested in each backlog item.

If you do not record actuals, and you had to invoice team time weekly, what would your invoice contain? A list of product backlog items actually worked on? How would derive the hours to charge?

Or would you use a completely different approach to working out what to bill?

Another way of looking at the problem is... if the customer wants to see how much hrs you have spent on a product backlog item at a point in time, where would you pull that number from?

Thanks,

Mike

Re: Time keeping?

gabriel.lozano-moran 04-02-2007, 9:16 AM
I have the same question. Although I understand the philosopy behind Scrum where the remaining work is more important than the actual worked hours, I still need to track this for billing and to improve our estimation skills. What I have done so far is add a field to the WIT of the SBI's called "Completed Work", I have also added this field to the PBI's. When this field is changed on the SBI's I update the total hours "Completed Work" on the PBI in the same manner that Conchango updates the "Remaining Work" thus using a service and subscribing to the work item changed event.

Re: Time keeping?

sherlock 04-20-2007, 11:29 PM
>I still need to track this for billing and to improve our estimation skills.

This was my reason as well. I customized the scrum template to add the fields needed to follow Joel-on-software's best estimation practices. This works great for us!

http://www.joelonsoftware.com/articles/fog0000000245.html

Re: Time keeping?

mdw_cubed 04-25-2007, 2:46 PM
Sherlock,

I'm finding that I'm tracking this information seperately and asking developers to give me an idea of how long they have spent on the project at each daily review.

It would be much easier if they recorded this with the SBI. Any chance you have a URL pointing to how you customised the template? Or maybe a summary of what you modified?

Re: Time keeping?

fretief 04-26-2007, 8:13 AM
We have the same problem with time keeping. Despite Scrum focussing on how much work is left Finance needs to know how much work has been done. (You know how it is ;-) We also use actual work done to review and improve our estimation. 

We do the following: 
1. We create a snapshot of the sprint backlog at the start. (Excell sheet with project plan which is approved by both the customer and the scrum master. This triggers the sprint and is the initial contract.) 
2. During the sprint the developers update the estimated effort to show how much effort the task will require in total. 
3. The work done then becomes estimated effort - remaining work. 
4. We also track estimated effort on the burndown chart to see if new work is uncovered or tasks removed from the backlog. 
5. At the end of the project the estimated effort equals the total amount of work done on that item. We compare it with our initial estimate and see how well we estimated. 

'hope this helps.

Re: Time keeping?

sherlock 04-27-2007, 9:28 PM
"Any chance you have a URL pointing to how you customised the template? Or maybe a summary of what you modified?"

Take a look at the URL I referenced above. Compare the fields Joel uses in his Excel template to what exists in your Sprint Backlog Item. The slight differences are obvious and quick to add.

Re: Time keeping?

JWK 05-26-2008, 4:35 PM
Hello,

does anybody has experience with TeamDef:

http://www.applicationaspect.com/SiteSections/ProductCenter/TeamDef/Welcome.aspx

I am curious about some user experience with this program. Perhaps somebody can post it on this topic. According to the website this program provides a solution for time tracking in TFS.