VS Scrum Process Template Release burndown

Question

One of my clients is using the VS Scrum process template.  Unfortunately, their release burndown chart is showing the cumulative effort for *all iterations* including those outside the current release. Only Release 1 iterations are shown in the Sprint drop down if I go to the Report site, but PBIs outside/above of Release 1 are included in the aggregate. What would cause this?

Answer 1

Hello Ryan,

Thank you for your question.

I am currently looking into this issue and will give you an update as soon as possible.

Thank you for your understanding and support.

Have a nice day.

---

Vicky Song [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

Hello Ryan,

I am sorry I can’t better understand your issue. Could you please show me some screen shots to describe your question?

I did a research on my PC, and found when I access the Report Manager the Select All option is selected by fault. And the Sprint work items can be shown in the report only if they have value of both Start Date and Finish Date.

I look forward to hearing from you.

Thanks,

---

Vicky Song [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 3

I'm not sure how to send you screenshots really.  Since Release Burndown is for historical data, showing you our current sum of effort would be inconsistent with our previous.  Let me know what screenshots would help and I'll post them.  If a livemeeting would be easier, I'm game.

Answer 4

Maybe these will help...

http://yfrog.com/h5jer4p (These are the Sprint work items with Start/End dates)

http://yfrog.com/h35gzp (This is our Release burndown as it exists - it's very wrong by the way)

http://yfrog.com/gyfbbup (A manual pull of the Estimated Effort of Work Items in states New, Approved, Committed as of 1.9.2011 which was the end of /Release 1/Sprint 15)

 

One thing to note, we pulled all of our work items from a previous TP using the Conchango template (now on 2010).  This was done before Sprint 15 as you can see by the Release burndown having no information prior to that sprint.

Answer 5

Ping.

Answer 6

I'm experiencing the same issue. Was a solution ever found?

Drew

Answer 7

No, but I have a better repro.  Hopefully they are still listening.

 

Here is my Release Burndown for today, the first day of Release 1\Sprint 17.  Effort is an incorrect 625:

http://yfrog.com/hs5hnp

 

Here is a warehouse pull of all Work Item effort Effort excluding States Done and Removed for all of the Team project in question.  There is NO iteration path filtering going on.  It states effort as 625.

http://yfrog.com/h0t8tmp

 

Here is a Work Item Query from Product Backlog with the query modified from Iteration Path = @Project to Iteration Path under @Project.  I've then, in Excel, filtered to included all work items with iteration Release 1, Release 1\Sprint 16 and Release 1\Sprint 17.  We haven't marked an item complete from the sprint that ended yesterday, which is why Sprint 16 shows.  Point being it includes everything under Release 1.  Here the sum of effort is 310.

http://yfrog.com/h0efotp

 

Here is an OLAP excel spreadsheet which is now filtering to only show Iteration paths under Release 1.  This states effort is 310, matching the Work Item query:

http://yfrog.com/gzl4up

 

Hopefully this shows that the report is not showing what it should.  I have seen the report work correctly and have other projects using it correctly.  There appears to  be something wrong with this particular Team Project.  

I should mention that I've pulled the rdl into a Reporting Services 2008 project and run things like the dsSprint query and I'm not sure how it is filtering by iteration path.  I do see how it chooses the date, but the dsBurndown query doesn't seem to filter by iteration path ever.  I'm by no means a Reporting Services or MDX guru, so take that with a grain of salt.

 

This is a big issue for my project right now.  Thanks for the help

Answer 8

Did your team project perhaps start out with the Agile template, then get migrated to the Scrum template after its release? (That's the only oddity I'm aware of for my project that's experiencing this issue.)

 

Thanks for documenting the issue.

Answer 9

No it was created explicitly to start using the Scrum template.  That said, I do see a number of Team Projects that were deleted by the same name.

Answer 10

Hi Ryan,

 

We are also experiencing results in the Releas Burndown report. We cannot figure out what data is being used.

Have you found a solution or good explanation of the report?

 

regards, Felix

Answer 11

Please vote up this connect: https://connect.microsoft.com/VisualStudio/feedback/details/642836/vs-scrum-release-burndown-does-not-filter-by-release

Answer 12

The Connect URL is showing as Fixed but there is no comments to indicate what the fix is or how to get to it.

 

Has anybody found an answer to this issue? It is very hard to use Scrumm effectively with Release Burndown reports not working. I would rather fix this in TFS but if we can't get a fix then we will probably have to change tools.

Answer 13

No fix here, and we desperately need these now.

Answer 14

Vicky,

Was there ever a solution to Ryan's question? This is the second round I am using this process template and I have the same issue with the Release Burndown chart not showing a correct effort value.

Justin

Answer 15

Hi,

I found the origin of this behaviour:

The problem is in the reports' query itself.

The report is supposed to sum all the values in PBI's Effort field, but if someone makes more than one change in a work item in the same day, every change will cause the report the  to sum the Effort field once again.

For example: if I added a PBI and set its effort to 100, the report will consider it as 100.

If I will change its state (in the same day) from New to Approved and save the work item, and afterwards change its Description (also in the same day) and save it once again - the report will sum its Effort 3 times (300, in this case)

The query itself should be changed to consider only the latest version of each work item in each day.

---

omerp