Story Estimates vs. Task Estimates

[Chad]

This perhaps is just more of a training/educational gap on my part, so thanks for your patience as we are new to the tools. When I create a new story in TeamPulse I can define my estimate. We would use this in context of hours to complete this story. However, when we decompose into tasks, we are adding PERT estimates and work remaining onto these tasks. One would assume the cumulative total of hrs on task estimates would roll up to the Story estimates, but there seems to be no correlation between the two. 

I am also trying to understand how these are reported or understood in analysis as well. If I am viewing my time spent on the work and have 200 for the story estimate and 100 on related task 1 and 100 on related task 2 - am I only indicating 200hrs total for the work involved to complete the 200hr story? Or am I skewing my data and showing now 400hrs for what was intended as only 200hrs work?

I am just now planning our first sprint and want to understand this relationship between estimates on stories and tasks so that we know how to plan and schedule properly. I cannot find anything useful on this topic in either the user guide or how to videos. I am hoping someone here can enlighten me. 

Thanks in advance,
Brian

[Steve]

Hi Brian,

We purposely decoupled the estimates on tasks from the estimates from their parent item (Story, Bug, Risk, Issue) to support the ability for people to estimate the items using different measures.

It's a common Agile estimation technique to estimate stories (and other larger pieces of work) in relative points and not in actual hours. It equally as common to estimate smaller tasks in hours (with the goal of keeping the estimate to no more then a few days worth of work).

With TeamPulse, we didn't want to automatically roll up and calculate the estimate to allow us to support this method of estimation.

That being said, it's a common feature request that we'd like to support in the future. In our last release, we added the ability to view a rollup of all the task estimates for a parent item. At the bottom of the task pane in the story, bug, issue or risk overlay, you can a calculation of various rollups. We plan on taking this information and displaying it in other areas of the application so that people can get a better view on the total task estimates for an item.

We currently don't have any plans to replace a parent item's estimate with the rolled up estimates of it's tasks. If you wish to see us implement this feature in the future, please visit our feedback portal and suggest the item there and encourage other to vote the item up.


Kind regards,
Steve
TeamPulse Product Owner

[Chad]

Hi, I have run into another education gap here related to this question. So, we were on the route to begin working with Story points as opposed to hours for story estimation but ran into a snag when it comes to iteration planning. The Story Estimate field is tallied and displayed in the capacity used part of the screen, but I am wondering how one determines your capacity in terms of story points? Capacity in terms of hours are easy - I have 1080 development hours each month. Given that we don't even have a baseline 'velocity' yet, just not sure what Telerik's thinking or ideas were behind how to populate capacity?

Also and related is the question of testing. How do customers typically handle testing in TeamPulse? We typically have included development hours + testing hours = total estimate, but whereas my developers are give 100% availability, my testers could be anywhere from 20%-100% available. My trouble with including this in capacity is that it skews the hours available for development.  However, I need to log testing time against the tasks as well. Just curious if there are any use cases or examples someone might have to help me understand how to work with capacity management and iteration planning in TeamPulse?

Thanks!

[Steve]

Hi Brian,

We ran into the exact same issue here when the TeamPulse development team switched from estimating in days to story points.

We addressed this issue by asking each team to look at a ordered list of stories that had been assigned story points and then estimate how many of those items they felt they could complete in two weeks (which was our iteration length). Both teams felt that they could complete stories that totalled up to ~21 points.

That's the number that we based our capacity range on. Over the next few iteration's, we discovered that the team's velocity ended up being in the 20 to 30 range, so we weren't that far off.

I encourage you to include testing effort in your estimates. That's what we do here and it's generally a good practice.

For each story that we have, we include at least one testing task and that task has hours associated with it.

The story point estimate that the team gives for a story should include the testing effort, which means that you need to include people who understand testing when you're assigning estimates to stories.

The larger issue you seem to have is that you don't have any predictability for access to testers. correct? If that's the case, then it's going to be difficult for you to have any planning accuracy. If the items that you're working on need to be tested before it's considered to be completed, and the people responsible for testing your work aren't available with any predictability, then planning with any level of accuracy is going to be difficult.

I'm not sure any tool is going to be able to help you with that.

Agile planning can be a little bit of a challenge, but there are great benefits once you get the hang of it.

This book helped me a lot. Agile Estimating and Planning.

Our own VP, Joel Semeniuk, gave a talk at TechEd on this topic as well. http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AAP309

Good luck.

Greetings,
Steve
TeamPulse Product Owner

[Jim]

I have a similar question for this thread.  We are estimating our stories in points and obviously our tasks in hours.  However, I would like to determine individual capacity in hours, ideally you do not want to load someone up at 100% capacity - so for a given 2 week sprint we would have 9 working days @ 8 hours each, but we would set our capacity at less than 72 hours so as not to max the capacity for each individual.  Ideally we would do something like 63-64 hours capacity for each team member.  As we are tasking out stories for each sprint I would like to be able to track against that individuals capacity so I can see when they are nearing or overcommitting themselves in terms of hours.  Is this possible in TeamPulse or is this something I would have to do manually?

Thanks in advance!!

Jim

[Jordan]

Hi Jim,

We don't have the ability to track individual capacity against the assigned work. This is in our backlog and you can vote for it Calculate iteration capacity based on the sum of the team members capacity.

Meanwhile I would suggest to use the velocity reports to come up with your capacity. Based on the previous iterations you can calculate the capacity. Read more http://www.telerik.com/agile-project-management-tools/support-resources/faq/analysis-and-reports.aspx#28aef556-cfb9-4cbb-9179-cdf77c0de4b4

Regards,
Jordan
Telerik