2

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.

Squid
  • 131
  • 2

2 Answers2

7

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.

Gort the Robot
  • 14,733
  • 4
  • 51
  • 60
  • I have been standing up to them for ages - but unfortunately just get told to do it. Part of the problem is that we aren't a true project team, we also do a lot of BAU work supporting more than 40 apps, and we are trying to shoe horn that into an agile process. In my view many of these extra stories bought in are not truly urgent and we are bringing them in at the peril of planned and prioritized work which is actually more important. I am looking for the hard data to support this... – Squid Apr 07 '15 at 00:38
  • 1
    Best you can do is to try to track all work the team does with story points. – Gort the Robot Apr 07 '15 at 01:50
  • I'm going to have to disagree, I am sure there is enough data in the warehouse to determine if a work item has been added to an iteration within the boundaries of the iteration... I am working on a query to get this, but it doesn't have 100% of my attention at this time, I'll post it once I get something I am happy with. – Squid Apr 08 '15 at 00:24
1

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 = '\TeamProject\Team\Sprint 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)
Squid
  • 131
  • 2