Over the past three years, I have served as the ScrumMaster for an ongoing, evolving project with two different teams. The project transitioned from R&D at one company and is currently in the stages of implementation in a production environment at another company. During my work on these projects, I have employed either the Basic or Pro version of ScrumWorks. It is a tool I appreciate not only for its features, but for its simplicity. Do not let the simplicity fool you, however, as there is a lot of power in the tool.
ScrumWorks Pro has the ability to interface with Bugzilla, which makes it perfect for working with the Bugs Dashboard as well. One issue that a Scrum team faces is dealing with the unplanned, unexpected events which arise during a sprint. For example, if a bug is found in a previously released product update, the time required to address it affects the velocity of the team. This impact is difficult to predict and varies from sprint to sprint. In many Scrums, this is an invisible impact as it is not recorded against the product backlog. ScrumWorks Pro helps to make the issue visible within the sprint by importing the issue from Bugzilla. It helps to keep the team focused on issues and allows the team to determine the necessary trade-offs if the impact becomes too great. This can aid in planning and review meetings where you break down the tasks required for the sprint.
My Goal For Integration As A ScrumMaster
I use a custom field in Bugzilla which allows me to correlate issues noted in Bugzilla with sprints in ScrumWorks Pro and a portlet in the Bugs Dashboard. What I am looking for is the impact issues raised in Bugzilla have on the current and imminent sprint. By keying the portlet on a custom field, I can easily track the estimated impact of a Bugzilla issue as shown below.
The portlet shows me what the estimated work required is, how many days remain in the sprint to accomplish what is required and the urgency (priority and severity) of the work. I can easily use this information to communicate with the Product Owner, stake holders, customers, senior management, etc. using the other features of the Bugs Dashboard, e.g. Set Priorities.After importing the Bugzilla items into ScrumWorks Pro, I can use the custom field to associated the Bugzilla item with the proper sprint (through drag-and-drop) as show below. Now, I have the information necessary to conduct a planning meeting with the team using the importance of the Product Owner to provide the necessary context to go with the issue.
I actually conduct several planning meetings during each sprint. The initial planning meeting is long enough for us to get the necessary details for the expectations of the sprint and the initial, immediate goals. I then hold other planning meetings as issues, such as unplanned tasks arising from bugs, come to light.Integrating Bugzilla, ScrumWorks Pro, and Bugs Dashboard allows me to manage the tasks expected in each sprint. You may ask how the Bugs Dashboard plays into this – where is the link?
The Importance of Bugs Dashboard To The Process
When issues arise during a sprint, they impact a team in many ways. They may affect morale if they appear to indicate a poor quality product. They may affect team dynamics if it is perceived that the bugs come principally from one person’s contributions. They almost always increase the pressure on the team through an increased sense of urgency to meet the previously stated goals of the sprint (which may already include other Bugzilla entries) and the new “pop-ups”.
The Bugs Dashboard aids in classifying the issues as a matter of the product owner’s point-of-view vice the report. For example, someone may feel that a relatively obscure bug is preventing them from using the system because it affects something they have an emotional attachment to. I say obscure because few users utilize that same function and thus there is not a great many users requesting the “fix”. The team’s desire to address that three weeks from now, in the next sprint, could be viewed negatively by the end-user. By allowing the Product Owner to specify the importance, I have the ability for the user to express their view, the team to express theirs, and the choice to be the Product Owner’s. With the Bugs Dashboard and ScrumWorks Pro, I can give the Product Owner the information necessary to make the tough choices. Perhaps something must be given up in the current sprint to meet the emergent need. Perhaps the emergent need can wait or perhaps additional resources must be authorized to deal with the need. Bugs Dashboard provides the right information and the right tools for these decisions to be made with minimal pain.
How-To Integrate Bugzilla, ScrumWorks Pro and Bugs Dashboard
Physically, it is simple to integrate the three products: just follow our “How-To” guide. The reason I direct you to a separate page is because there are over 20 screen shots to guide you step-by-step at that page.
Mentally, it may not be as easy to integrate the three. That is because you have to “herd the cats”. The bug reporter has a say in how a bug is interpreted and may need to be consulted further, but handled gingerly while separating the emotional ties to the issue. The team may need to be consulted to ascertain the expected impact of addressing the issue – an interruption to their current work knowing you will be asking them to perform the new work. The Product Owner may need to be consulted to provide the give-and-take on expectations for the sprint – and giving up expectations is never an easy thing.
My Approach
There are several approaches to how to handle interruptions of this nature. The one I favor is to create a separate product backlog item in each sprint for “unexpected events” from the very start. Initially, this is a low budget item – perhaps 4 hours in a 4 week sprint. As the sprints build, this number usually increases due to more functionality that must be maintained, a large installed base, larger code repository, etc.
Unexpected events can include bugs which arise and are deemed urgent enough to be addressed in this sprint. It can also include technical debt which must be paid back through refactoring, increased demand for documentation, loss of work due to sickness, etc. The cool thing is that the team can fill any unused time with additional tasks from the uncommitted backlog should they get the opportunity. Only the team can add items to a sprint after it has started.
Must Haves
Each of us has a style and we all have our individual preferences. For me, and I may be biased – I admit it, the best approach I have to managing the complexities of a project in a simple fashion is to use Bugzilla, ScrumWorks Pro and Bugs Dashboard. these are all “must haves” for my toolbox!
bugzilla