single backlog requirements & incidents

Tuesday, August 6, 2013
Avatar
My team is trying to manage everything in a single backlog. They want everything they are going to work on in a sprint(iteration) in one backlog regardless if it's an incident or a feature.

Additionally, my PM/Managers want to know what bugs were found and/or resolved in the current sprint *and* how many bugs we are worried about. 

For example: The team agrees to pull in 10 bugs to resolve at the beginning of the sprint(iteration). During the sprint(iteration) we find 10 others, agree that 5 are severe enough to address this sprint(iteration) and the rest will go into our backlog. There are now 15 total bugs that we will fix this sprint and 5 we will leave for future sprints.

I cannot figure the *single* place to find this information in Spira. At this time I know the Main Project Page --> Incident Summary will show the incidents found during the iteration when filtered properly and the Reporting --> Incident date range graph will show what we have fixed/found during the iteration (when filtered correctly) but neither address showing what we are starting the sprint with. 

WE've tried the "Create a requirement from this incident" but this creates it's own issue as the requirement is not updated as the incident moves through the workflow which requires the developer to update multiple fields when resolving issues. 

Is there a simpler way for the PM/Manager to get the data or is the developer right and he has to spend 4 days to build a tool to get the custom data by tagging the db through the API?
2 Replies
Tuesday, August 6, 2013
Avatar
re: davist Tuesday, August 6, 2013

Hi Tonja

Generally, the place to look at all the items to be worked on during an iteration / spring would be either:

  • Planning > Iterations
  • Planning > Planning Board

Regards

Adam

Wednesday, September 18, 2013
Avatar
re: inflectra.david Tuesday, August 6, 2013
Tonja,

I have also fought with this issue, and have had to work around the tools limitations. My general approach is to make sure everything is a requirement, as that appears to be the sole view that can give me insight as needed; Planning -> Requirements. With regards to defects, the only way is to generate a requirement form the incident and then we preface those with DEFECT: so that we can identify them in the aforementioned view. As you noted, changes to the requirement are not captured in the incident but there is an association created when you create the requirement form the defect. I have hard that the next release is supposed to mitigate some of these non-Agile approaches that have been forced in to the workflow of the tool.

Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885

 

Statistics
  • Started: Tuesday, August 6, 2013
  • Last Reply: Wednesday, September 18, 2013
  • Replies: 2
  • Views: 2876