I am looking for a report to capture the “Scope Creep” within an iteration. We are using Scrum on TFS 2013 on premise.
We are constantly asked by management to bring work into an iteration, but are still pressured to meet the commitments made in the planning meetings. Unfortunately it happens often enough that it isn’t a matter of manually tracking 1 or 2 work items per iteration.
Also sometimes we have just underestimated work and it takes longer than we had planned.
I would like to pull a report from TFS or the warehouse/cube which shows when work is brought into an iteration (i.e. new PBI/Bug added) or work on an existing item increases.
I would like to use this report to show management the impacts of bringing in unplanned work and/or use the report as data to improve our estimates.
The official Agile answer is that this simply should not be allowed. Unfortunately, as you are experiencing, the reality is that this often happens. Sometimes this is because business requirements change too rapidly even for short sprints. Sometimes this happens because of pure bad planning on the part of the product owner. And unfortunately sometimes this happens because management has not truly bought in to agile and therefore feels they have the right to tell you to do whatever task whenever. This last case is the hardest to deal with.
First, when accepting a new story into a sprint, it should be pointed just like any other story. All work should be tracked regardless of whether it was added to the sprint the right way (in planning) or the wrong way (at random during the sprint.) You should know your velocity. You should now how many points you agreed to do in planning. If you point new stories, you should be able to tell exactly how many extra points you are required to do. You can therefore report during each sprint how many points over your velocity you were asked to do. At the end of each sprint, you can therefore show that you were late on X,Y,Z because you were asked to do new stories with numbers of points that put you over your velocity.
The second thing you can do is to track how many points of properly planned-at-the-start stories you are able to complete and use that as your velocity when planning. Be very transparent about this. Make it clear to management that you are unable to take as many stories as you otherwise would because you are being forced to do extra, unexpected work.
It is an unfortunate truth that for this to work, you will have to stand up to management and explain that in order for agile to work, agile rules must be followed. This can be hard or impossible to do if management is poor. But it must be clearly explained each time stories are added mid-sprint that you can’t get the benefits of agile without following the rules of agile, and avoiding mid-sprint work is one of the most important ones.
3
Here is a script that I prepared that will look through the workitemhistory view to work out when an iteration changes on a date which is between the iteration start and end date.
It is a work in progress, but it demonstrates that the answer is there if you need it.
DECLARE @iteration VARCHAR(300)
DECLARE @startDate DATETIME
DECLARE @endDate DATETIME
SELECT @iteration = 'TeamProjectTeamSprint 4';
SELECT @startDate = startdate, @endDate = finishDate
FROM DimIteration
WHERE iterationpath = @iteration;
WITH CTE_ALLWorkItemsInIteration
AS (
SELECT DISTINCT system_id
FROM WorkItemHistoryView
WHERE IterationPath = @Iteration
)
,CTE_WorkItemHistory
AS (
SELECT *
,ROW_NUMBER() OVER (
PARTITION BY System_Id ORDER BY [System_ChangedDate] ASC
) AS Recency
FROM WorkItemHistoryView
WHERE system_id IN (
SELECT system_id
FROM CTE_ALLWorkItemsInIteration
)
)
SELECT CurrentWI.System_id
,CurrentWI.System_WorkItemType
,CurrentWI.IterationPath AS currentIteration
,PreviousWI.IterationPath AS previousIteration
,currentwi.system_changeddate
,CurrentWI.System_ChangedBy
,CurrentWI.System_Title
,(
CASE
WHEN CurrentWI.IterationPath = @iteration
THEN 1
ELSE 0
END
) AS AddedToIteration
,(
CASE
WHEN PreviousWI.IterationPath = @iteration
THEN 1
ELSE 0
END
) AS RemovedFromIteration
FROM CTE_WorkItemHistory CurrentWI
LEFT JOIN CTE_WorkItemHistory PreviousWI ON CurrentWI.System_id = PreviousWI.System_id AND CurrentWI.Recency - 1 = PreviousWI.Recency
WHERE (
CurrentWI.IterationPath <> PreviousWI.IterationPath
OR PreviousWI.IterationPath IS NULL
)
AND (
CurrentWI.IterationPath = @iteration
OR PreviousWI.IterationPath = @iteration
)
AND (CurrentWI.System_ChangedDate BETWEEN @startDate
AND @endDate)