Loading Profile...
Twitter,
Facebook, or email.
EMPLOYEE
Hi there,
We're currently evaluating ScrumWorks Pro and so far we really like it.
Today I was looking at its reporting capabilities and timesheets.
Maybe I'm missing something here but I can not see, for completed tasks, what was time allocated for them at planning stage.
You can see how much time was spent (with breakdown by day and person) but no information how much time we thought it would take.
This information would be very beneficial at sprint retrospective meetings were we could discuss over and under estimated tasks/PBI.
Also, as it's not advised to change PBI effort once it's commited into a sprint, it means that PBI's effort might have nothing to do with real effort that was required to complete it so PBI's effort is not useful either.
Any thoughts Lads?
Thanks,
Marcin
Track Task Time spent vs time planned (estimated vs. actual)
-
Hi Marcin,
You should be able to find what you are looking for by opening up the Sprint Detail View, by double clicking on the sprint in question (just the red bar should do it).
From there, check the box: Show Estimate History. This will give you a day by day breakdown of the hour estimates for each task. Additionally you can choose to export this to excel (just like with the timesheet).
Generally when I work with teams that are looking for some numbers to get better at Task estimation they will use exports from the Timesheets and the Show Estimate History to compare.
In terms of the Task Hour Estimates having a bearing on PBI estimates, that goes a bit down the Scrum Process rabbit hole. I would suggest reading This Whitepaper by Michael James on the subject. Additionally you may want to read this blog entry by Jim Schiel, I think it might explain why ScrumWorks focuses on separating PBI estimates and Task estimates.
If you have any more questions on the subject be sure to let us know.
Caleb Brown
Danube Technologies, Support Manager
** Feature requests? Tell us about them here: http://community.danube.com/danube/ **Comment -
-
Hi Caleb,
Thanks for your answer. Did not spot "Show Estimate History" checkbox before. Yes, it helps to some extent.
But what would really help would be to be able to display original/first task time estimation column next to "Total Spent" column on the Timesheet tab.
It would allow you to see at glance where your estimates were ok and where they were not so ok.
Thanks, Marcin -
-
-
-
Hi Finms,
From the tool side of things the only way to achieve what you are looking at doing is to export both reports and use Excel to work up a comparison. There is reasoning behind why we don't provide this.
I need to check with one of our trainers, he told me he was going to reply to this for you, I will find out if there was some sort of technical difficulty. -
-
Hi Caleb and Finms!
this is something that our team is also facing. If team member needs to add more hours to some task, you don't easily see the used hours from the tool.
For example if we use only 'Show Estimate History' option we see situation per day but the situation could be that on 23-Sep specific task is in 'In Progress' state with 5 hours remaining. On 24-Sep team member continues working with the task but notices that the task is bigger than planned and end of day he updates situation to the tool with values task is 'In Progress' state and remaining hours are 5.
=> now you can't see hours spend to this task from the tool. You only see with 'Show Estimate History' that task remaining hours have stayed in same level for couple of days and you can easily make assumption that team member wasn't available to work with task on 24-Sep although the situation was totally different
So, I'm also backing the idea to add column 'Total Spent' to the tool or do you have any good ideas how to EASILY find this info from the tool (not creating excel exports => doing that too often isn't good user experience)
~Anssi -
-
EMPLOYEE
I’m
undecided
There are lots of philosophical reasons why we don't yet have an explicit "Estimated vs. Actuals" capability in ScrumWorks Pro. You can find some arguments against doing this here.
I'm open to considering this feature if there is a pressing need. If you need a feature like this, please vote this item up and leave your comment in this thread.-
I just wanted to note here that the link has changed, the updated Macro Measurements pdf if available at this address.
-
-
-
-
-
I don't fully understand the philosophy not showing task estimates in the tool.
For our team it could offer information how well we have been estimating our task lengths. E.g. if our previous sprints show that it's normal for us that task lenght has been estimated to take 10 hours and actual time used for implementation has been something like 20, we would notice that our planning has been too loose.
“Not everything that can be counted counts and not everything that counts can be counted” (Albert Einstein) -
-
Hi Zotte,
Task estimates will be reflected in the tool. If you go into the Sprint Detail View and select Show Estimate History, the estimate for every day will be displayed. So if something was originally estimated at 4 hours and then 2 days later was increased to 10 hours that will be reflected there.
The same will apply to the Timesheets, except that they will be recording time actually spent.
What ScrumWorks currently does not do is to automatically take the data from the Time sheets function, and compare that to the Estimate history. Adding a report that does this for you automatically is really what this debate has been about. -
-
Zotte asked about the philosophy behind this debate.
A commonly accepted notion within the Agile community is that task estimation is inherently inaccurate because there is far too much uncertainty at the task level due to the novel nature of the work. See Craig Larman's book on Agile and iterative software development for a really strong argument on this topic.
In essence, there's no way to get good at estimating at the task level because each foray into a new feature or project is fraught with unforeseeable uncertainties. In our experience, even the best developers in the world cannot estimate tasks precisely. This is a universal problem.
Note, this doesn't hold true if you're doing the same thing over and over; repeatable work can be estimated at the "task" level.
So the philosophy here is - why try to do something that's impossible? Why focus on a metric that is inherently flawed? Instead focus on "macro metrics" (i.e., velocity at the story level) and get away from task level metrics altogether.
By enabling task level metrics we enable this "bad practice". Hope this helps! -
-
Hi Victor,
You said yourself that repeatable work can be estimated at task level.
It might happen that you work on new functionality but some of the building blocks are universal/standard/common.
In this case estimating these with help of historic data wouldn't be that bad, would it?
Also this kind of report that would show original task estimates vs actual time spent would be very helpful at sprint retrospective.
It's purpose is to discuss among other things "what went well?, "what could be improved?", "what did we learn?"...If you can see that you greatly underestimated (overestimated) a task, then you've learned that next time you should allocate more (less) time for similar endeavours.
do -> learn -> incorporate -> improve -> do
Thanks,
Marcin-
Hi Marcin,
I'm certainly not taking a dogmatic stance about this issue. I personally doubt that much of software development these days is "repeatable", like a manufacturing line, but perhaps there is more repeatable work then I think. If you feel there is value to such a report/feature, please vote this item up by clicking "I Like This Idea" at the top. Thanks for all the feedback! -
-
-
-
-
I understand the philosophy. I am neutral.
Question: Does your data model support Tracking Time Spent against the estimate history. Do you have a data model? -
-
Hi ldiaz,
You can optionally track time spent on a daily, task by task basis, by enabling the Timesheets Function in each product. The estimate history is also tracked by task and day.
So, while we don't explicitly provide a report that compares the two, everything is there to build your own reports. This is commonly done by exporting the Timesheet, and the Estimate history, both to .xls spreadsheets, and comparing the two. It is also possible to access all of this data through the API.
Hopefully this answers the question. If I misunderstood what you mean by Data Model let me know. -
-
I don't actually understand all the resistance to this great proposal. We want to be agile not religious. I would very much welcome this data, as it's important to know how much was actually spent on any single task and how much was initially estimates as well as accumulated estimate.
As i understand you have the data but are suggesting to us that we should export to another tool and do it. Why? I value this tool only if i can do all my stuff in it. If i have to use excel, of course i can use it altogether instead of scrumworks.
If you think it's not agile to get this data, make it an option to enable/disable the features. I think it's an easy feature to add, and several people i have talked to are not using scrumworks pro exactly because of the lack of proper access to hours spent compared to hours estimated.
Thanks
Abid -
-
Abidt,
I completely agree. I have been using ScrumWorks for 3 years at customers that are new to Agile. This is an industry that is reluctant to change, but would like to gradually transition.
Agile is about an evolutionary change not a revolutionary change. Time spent reports help the transition.
The issue as I understand is that consultants of Danube are really against the idea of time spent, and therefor prevent product development from making these changes.
If Danube does not fill the gap, another product will.
Cheers,
Luis -
-
Thanks to everyone for the continued feedback. Keep clicking the "I like this idea!" button up top and we'll get around to building this sooner than later.
Regards,
Victor Szalvay
ScrumWorks Product Owner -
-
EMPLOYEE
I’m
looking for feedback.
Clarifying question to all you:
What would be the scope of this report? That is, how would you want to limit the data displayed? Obviously there needs to be a limit in terms of time; you don't want to have to wade through historical data each time you view the report, but how else would you want to serve up this data?
Some possibilities:
1. - Filter by team (shows all tasks across all products)?
2. - Filter by product (includes all teams for the product)?
3. - Filter by product and team (includes a single team on a single product)?
4. - For all users (no filter)?
My guess is that you'd want to run this on a single team for a single product (option 3).
Please let me know so we build it right. -
-
I'm very happy to hear that you will be including this feature, and here is my feedback of what i need.
i would run it for a single team for a single product.
I want to see the original estimate, accumulated estimate, accumulated hours spent on a task (all users), and even be able to split this into what user spent how many hours on this task.
And i don't want to think about this as a a report. At least for the accumulated spent hours, i would prefer it to be a column next to Task hours. -
-
I’m
happy
We would also normally use this for a single team on a single product.
Thanks
Mike Brown
ProQuest -
-
For us usage would be for a single team on a single product...
-
-
We have been reviewing ScrumWorks Pro and the purchase was stopped because of 2-3 requirements that were not satisfied. One of them is reporting on individual level.(meaning Individual task) with possibility to aggregate to team /feature level.
This is the reporting that is required by our accounting. Scrum process does not live life of its own in vacuum. We have to relate to the requirements of the organisation around us. -
-
Dariusz,
Are you re-considering now? If so - please contact your account manager so that we can continue the evaluation. -
-
For Dariusz:
I've recently had to go through that issue with my new client (I'm consulting) who wanted the timesheets/financial breakdown based upon tasks, which seems similar to what you needed. That is not really scrum friendly, but there was still the requirement. So I convinced the PM/finance people to track time/costs per story. They seem happy enough now, even though it's not 'pure' as per scrum. It is at least a step in the right direction.
You may find that it could work at your company as well. We use the themes at the product level (and roll up to epics in the program) to track which budget bucket a story is being charged in. The timesheets for everyone has the story names (same as per SWP) + the usual extras (Sprint Planning/Review/Retrospective + generalized non-project codes). -
-
For the feature itself, I would ask that it be enabled/disabled at the product creation level, as per timesheets in SWP. It may even be best to tie it to the timesheets in SWP, since without the time sheets some of the functionality won't work.
-
Derrek, yes this feature would be disabled if timesheets are "off". Thanks for clarifying that.
-
-
-
-
-
OK, imagine a project with members from different companies. Imagine that they share not only features but also tasks (pair programming - just as an example). The project is to deliver the time sheets for each of the team members (so they get paid).
The hassle with additional time registration tools, verifying them against other sources of info etc etc.
Today's solution allows you to register hours / task (even with point person assigned). The only thing I am asking for is that instead of one to one relation between person and task the system has many to one. (one task -> many persons). Not more then that :)
For Laszlo:
I am just following further development of an otherwise excellent tool. When the tool has what we need we start reconsidering :)-
This is my current situation. There is at least 3 companies supplying team members for a project. We don't use the SWP timesheets, since the team has to fill out the timesheet for both their own company AND the client. Managing the line items in the timesheets is rather easy for us. Once the team commits to a set of stories for the sprint, that list (just the story names + which budget bucket it belongs within) gets sent to the companies to become the line items. As we only do this every 4 weeks, it's no hassle for us.
edit: I also created a web report which shows each story in progress filtered by the budget buckets. -
-
-
-
-
Thanks Darius -
Outside of this feature - what else does your team need?-
We definitely need to integrate ScrumWorks with Test Director.
-
-
sending you an email on this one Dariusz, I think we might have an idea in on this already here: http://community.danube.com/danube/to...
-
-
-
-
-
EMPLOYEE
1Take people's feedback into consideration, I came up with a quick excel mockup (screenshot attached) for purposes of discussion.
We'd add a new column to the sprint detail area "original estimate", since this is needed now. Notice in the mockup how we deal with multiple users contributing to a single task. We would not have separate "estimates" for each user working on a task since there is only a single task estimate.
Another question:
- We are thinking of using the "original estimate" to mean the first estimate given (we would make task estimates no longer "required).
- Should users be able to modify the original estimate number after the fact? My feeling is no, but I was curious what types of constraints you all would prefer.
Thanks!
-
I like the look of this report format.
-
-
-
-
-
What about the Web client? The changes would be needed in multiple areas.
Or is this just the 'report' view?
as per original task estimate... I would say yes let them change it as per changing the historical effort estimate. At first blush, someone might say 3 hrs and then 5 min later realize it's actually 5 hrs due to a new piece of information. No changes means they have to be right the first time, which is rarely the case.
Maybe allow modifications for a given time period if the task was in the sprint? Just seems a bit more complicated to not allow changes to the original estimate.-
Derrek - yes, my bad, I forgot to add that we'd change the editors in the task and web clients to reflect the new "original estimate" field. In essence this is a "report" though. Thoughts?
Using the historical estimation permission makes sense. Thanks! -
-
-
-
-
I take it this feature is now under implementation? When will this be released?
-
Right now we're planning on releasing it as part of 4.3, probably late-January time frame.
-
-
Timeline update: turns out there is a lot of ground work to do before we can support this report (related to unestimated tasks). As a result, we'll be releasing 4.3 without this feature in late January. I know... bummer. But we'll be back at it for 4.4.
-
-
-
-
-
-
is there any plan to release a free-basic version of scrumworks with this important feature?
-
-
-
-
EMPLOYEE
