Separating Development from Testing in a sprint as it relates to "Done"

Jon Radin

 I read-up on some similar questions and see that I might not be the only one who defines development work as "done" but still want to track testing/release which may fall into a subsequent sprint.  Any thoughts?   

As background, I primarily want to track our developer work and be able to use burn down/up reports to track progress.  Once finished and in UAT that gets tracked separately as some release builds take more than one sprint.  I do not want to lose track of UAT work for if there is a fail and re-work, that would be included in the current sprint.

Recommendations appreciated...as are the the timely responses you folks provide.

One option that was recommended was to create a separate story for testing.  This may be good, but what if there are several stories/tasks to a project...that may become cumbersome...?

 

Regards, JR

Trudy P Claspill

Copying my response from your original post, just to help get the conversation started...

 

In my opinion you have to decide what it really means for the work to be "done". If testing finds a problem, is the original story going to be reopened or is a new story going to be created? If the original story is reopened, then in my opinion the work is not "done" until testing is also done.

If you really want to track the completion of development (prior to testing) separately from the testing activities, then I would recommend that you create separate stories for tracking the testing activities, and link those to the corresponding development story. Then development and testing activities each have a workflow from To Do to Done that they follow, and the backlog and completed work for each type of activity can be tracked and visualized in Burndown/up charts.

 

Regarding your concern that method might become cumbersome, that would be the trade off to tracking development completion and test completion separately.

 

Another suggestion that has been made in the past is to create one board for development and a separate one for testing, and run separate sprints. In that scenario, you have one workflow for the issue that goes something like

To Do, Dev In Progress, Dev Done/Test To Do, Test In Progress, Test Done

In the development board you include only the first three statuses. In the testing board you include the last three statuses. The Dev Done/Test To Do status is just one status that is the end of the development board and the beginning of the testing board. In that scenario, closing a sprint in the development board while the issue was in the Dev Done/Test To Do status would consider the issue done for burndown/up and sprint reporting. There are problems with that methodology though, so if you are interested in it I would recommend setting up a test project with test issues and this workflow and running through some test sprints to see how it all works. Personally, I don't recommend this methodology.