Question

We have a mature product that we reuse for new projects. For one project, some tasks were created for already working features. Those tasks were all assigned 1 SP each. So, just as a sanity check, I went ahead and tested a release version of our product in order to close the said tasks.

Now, since I didn't do any work for those features to work properly, in order to reflect correctly what was done for those tasks should I close them unassigned in the backlog directly or put them in the sprint, assign them to me and close them? Am I wrong to assume that the first one would adjust the backlog SPs reallistically and the second option would give a scope change and a false representation of the burndown rate?

Was it helpful?

Solution

You say "I didn't do any work for those features to work properly" but that's not strictly true. While you didn't write any code, you did spend some time testing, and testing is valid work just as much as writing code is.

OTHER TIPS

Now, since I didn't do any work for those features to work properly, in order to reflect correctly what was done for those tasks should I close them unassigned in the backlog directly or put them in the sprint, assign them to me and close them?

IMO you did some work: you tested it. Therefore, I would include in the sprint, assign it to me and close it.

Am I wrong to assume that the first one would adjust the backlog SPs reallistically and the second option would give a scope change and a false representation of the burndown rate?

IMO since you "worked" in this task during the sprint (testing it and making sure it's still working in this new project), it's OK to have a scope change, and be able to see in the burndown that you added something and closed it.

Licensed under: CC-BY-SA with attribution
scroll top