How to record changes to tasks in sprint backlog?

Question

We are using Scrum for more than a year now for a mobile game project. We use a printed Excel sheet pinned on cork board almost similar to one here on mountaingoatsoftware website. During the sprint we need to take customer approval mostly for design to mark that task as done.

We put a question mark in the progress cell when task owner finishes the task, to remind us that it is pending for approval (it works same as zero on burndown chart except that we know that work is not approved yet), if work is approved we put zero, otherwise if customer needs some changes then designer has to incorporate those changes but we are facing a unique problem that we are unable to find a solution online.

The whole team is collocated except the product owner who gives feedback via email or chat. Now consider the following senario and help me solve the problem:

1. On Day-4 we have conducted the daily scrum, a task owner marked task-A as pending for approval by putting a question mark (i.e. he has consumed estimated hours and finished work from his end)

2. Scrum Master has taken notes from the sheet and generated Daily Burndown chart and disseminated reports to stakeholders

3. During the day the customer reviews the completed task and ask for some changes via email/chat

4. the task owner spends a few hours and completes those changes and send for review again

5. on Day-5 daily stand up meeting the task owner inform the team about the work done

My questions are:

• How do we report it on the sprint backlog? if we put a question mark on Day-5 then we will miss the hours spent on the burndown chart

• Should we put hours spent on Day-5 progress? but then work is in approval not in progress

• Should we add another task, record time spent in actual estimate column and question mark on the Day-5 progress cell? but then task-A remains incomplete. it also doesn't sound feasible as it happens to many tasks, and the approval cycle happens several times until task is finally approved.

• This additional work/changes certainly shorten the time for other stories pending, therefore how do we deal with this situation.

Answer 1

The goal if SCRUM is transparency. If your team has an approval process in place, a task isn't done until it is approved. All hours worked toward completing that task needs to be recorded. A simple solution is write in the extra number of hours (for example, every time you do more work add "+1" or "+4" to the task.

The other choice, as you suggested, is to add another task. Since this happens a lot, perhaps you need to include an extra task on every story for this type of work. If you know it happens, you should be planning for it. Add a task called "post-review work" and estimate how many hours you spend on average. Make that part of the plan.

this additional work/changes certainly shorten the time for other stories pending"_.

If by that you mean that it shortens the time remaining for other stories, then yes, it does. I don't know what you mean by "how do we deal with this situation?". You deal with it by recording all of the relevant information. If you get to the end of the sprint and some tasks are not finished, you talk about it in the retrospective and then work on the tasks during the next sprint.

The bottom line is that you need to track all time spent (or stop tracking time altogether and focus on story points and smaller stories). When you run out of time, talk about it during the retrospective and find a solution that works for your team, then try to do better the next sprint.

Answer 2

As @Martin Maat pointed out, you are allowing change of the scope of the user stories during the sprint, that is not a good practice (it can be from PO as well, does not matter). If this happens often it can be frustrating to the team and makes very difficult to plan releases.

Putting this aside, we can generalize the situation as in Scrum tasks can emerge as team knows more and it is not uncomment that some tasks just appear.

In that case I would simply create another tasks and estimate it. This additional task which was not previously expected can be displayed on burndown chart bellow zero line. This is a release chart in the same fashion but you get the idea.

Like this you can track how much you burn from the expected estimates and how much you added on top (bellow) that. As @Bryan Oakley wrote, transparency is very important. Like this it will be visible how much you spend on the additional findings every sprint and based on this adjust your way of work.

In one of the comments you write

In scrum constant feedback is important

I am not sure it is completely like that. Frequent feedback is important, but since situation is changing fast, it can happed that using constant feedback user story would be never finish because customer changes mind all the time. Try to fix scope at the beginning of the sprint. I cannot imagine how you plan sprints: Hello team, can you finish these five user stories in the next couple of weeks but keeping in mind that scope can significantly change? It just sounds weird.+-+ But maybe I got you wrong.

Answer 3

You are not doing Scrum. It may be agile but the way you let your stakeholders disrupt the sprint defeats the purpose of Scrum entirely. Scrum would be agreeing on some functionality to be built, then build it the way the team deems sufficient in the coarse of a sprint and then, at review/demo day at the end of the sprint, present the results to stakeholders. If stakehokders at that point are not satisfied, a new user story catering to their wishes may be taken into the next sprint.

The purpose of Scrum is to measure how well you are doing in terms of delivering expectations and gradually get better at that. The way you are doing it screws that over, you are not working to meet your sprint planning, you let yourselves being micromanaged and run after a moving target. At the end of a sprint there is nothing to compare to because you did not work to meet your own planning.

You should either stop pretending to do Scrum and get rid of everything you do now to make you feel you are doing Scrum (because it is waste), or politely ask your stakeholders to back off and save there reviews for demo day.