Please login or join to subscribe to this thread
Who is finding the issues, and at what point are they being found?
For example, if a developer finds an issue while working on a story, the developer would resolve the issue during the sprint that the story is being worked on. If the issue cannot be resolved during the sprint, the story goes back into the backlog, in theory, and the product owner decides whether to put the story into the next sprint, or a future sprint.
If you're looking at capturing and analyzing all issues, regardless of when they were identified or resolved, think of it this way - Scrum is supposed to have self-organizing teams. You could easily have the scrum master or product owner own the list, but how many people does the information need to go through before it gets added to the list? Who is doing what with the list, over time?
Are we talking defects or project issues? If the former, then whatever method the team has come up with for managing their defects in alignment with organization standards should be followed. If issues, then as the PM, you are accountable for maintaining and communicating that info but those closest to the issue are likely best suited to report and document them. An information radiator approach might be better than an issue log. If the issue is blocking work items, then making that visible on your work boards will help to create visibility and a sense of urgency to get those work items unblocked...
any team member should be able to enter issues and be assigned to solve issues. If an issue is seen as an impediment, the SM will be in charge. You might want the team to look at the issue list during in daily standups - and share new issues, resolutions.
Someone on your team may already act as a kind of document master (maintaining backlogs, sprint logs, team roaster/calendar, meeting minutes), so I would ask this person to extend his or her role.
Thanks all for the update and support,so I think that reporting the issue should be the team member closest to the issue responsibility and making sure the issue is reported should be the SM or PM.
Issues should go on the backlog. Anyone on the team should be able to add something to the backlog if they identify a problem that needs addressing.
All that means work to do must be inside the backlog. Issues means work to do then must be inside the backlog as @David stated above. With that said, the way to show it (user stories, use case, etc) and the "category" assigned to it (enabler, nfr, etc) will depend on the way you complete Scrum framework to manage this type of things. But the key thing is: what is not into the backlog does not exists. So, the backlog itself is your issue log.
I think I caused confusion between issue and a problem, to clarify more, for example during testing it was detected that we have an issue (problem) due to missing system configuration, since the tester is a different person from the developer (responsible for system configuration) the tester will wait for the developer to investigate and solve the issue which might cost a day out of 5 days of testing, communication between tester and developer can be done by using the agile software to assign a subtask to the developer.
However, my purpose is to list the issues , especially the repeated ones so that we can later use it in quality improvement and to serve as lessons learned in future projects.
so I think the tester here has a quality control role and should log the problem / resolution details in a list (log).
I agree with Sergio
Issue is a term normally referenced in waterfall. Issues are logged in Issue log, by the person facing the issue, and assigned to a resolution owner, who may in turn involve others as part of resolution process. Project Manager monitors issue resolution, identifies escalation points and reports on progress in issue resolution in dash boards.
In agile the terms that we use are Impediments, obstacles and blockers. Impediments are those that slow down or hinders progress, such as a delay in clarifying a business aspect of a user story. Obstalces are those that can be removed with some efforts, such as acording gate passes to enter a work spot to do work. Blockers are those that stop the work : ex: not having an extra software license for a new team member. The distinction between these terms are wafer thin and classifying them is left to the discretion of the team. Teams prioritize and classify using Fist of Five technique. Its maintained in radiator, and team members can themselves prioritize, de prioritize or remove them from impediments log. Most impediments can be internally resolved by self managing teams. Others, may require PO or Scrum Master's help. As SM I would estalish communication lines, appoints SPOC for each issue within the team but let the team members and stakeholders resolve the impediments themselves, without my intervention. The idea is coordination baton should still be held by team members. Even in Scrum of Scrums, I would as SM would take a team member in case depenencies need to be discussed. In our project, we had a mid-swim lane between '"doing" and "done" for user stories stopped due to blockers. Parking them in the mid lane would reduce the WIP count of the lane, and allow team members to take new work. In this way throughput will be maintained and the blocker in the task board would get discussed every day in the daily stand up. Teams can take action in case it doesnt get resolved soon.
Please login or join to reply