Translate Toolkit & Pootle

Tools to help you make your software local

User Tools


Implementing Scrumbugs for SCRUM management

Scrumbugs is a web platform that presents SCRUM management reports created from data stored in Bugzilla. This spec is about implementing Scrumbugs for Translate.

Rationale

Why are we doing this?

  1. To centralise the tracking of issues, bugs and stories in one tool instead of across multiple tools.
  2. To allow easier participation of the community in the scrum iterations. Either as observers or as participators.

Other benefits:

  1. We can change the code of Scrumbugs to add features that we might need.
  2. Bugzilla makes it easier to create hierarchies of epics and bugs.
    • No need to worry about tasks vs stories vs epics
    • Many-to-many relationships allow stories to be dependants of multiple epics.

Missing features

These are features that are probably beyond what scrumbugs does and that we'd need in the medium to long term to make scrumbu.gs work well for us.

  • Hide bugs. In some cases we are working on client implementations of features. There might be any number of reasons to hide this from the general public: security related issues, NDAs, etc.
  • Combine bugzillas. Bugs come from various sources: our bugzilla, mozilla, redhat, debian, etc. Instead of duplicating a bug in our bugzilla it would make more sense to interact with the upstream bugzilla thus engaging the reporting community directly. This allows us to easily slot bugs into an iteration no matter where they come from. Using our own bugzilla but linking through the See Also field could be a temporary solution.
  • Prioritisation. This is hard in scrumdo but it would seem harder in bugzilla. It would be beneficial if we could prioritise bugs in the same way that originate from bugzilla.
  • Epics. I'm not sure that the heirachies presented by Bugzilla are the easiest to use in terms of managing a story hierarchy
  • Client views. With certain clients we want them to see the SCRUM from their perspective. So it would be useful to have client specific views of the data. A client with a login would see their stories that would otherwise be hidden.
  • Burnup charts. Scrumbu.gs implements burndown charts while scrumdo implemented burnup charts. The advantage of the burnup is it shows points to complete as well as points completed giving a better management view.
  • Scrum board. There is no obvious scrum board in the traditional sense of stories in columns of todo, doing done.
  • Specs. While bugzilla is good for tracking discussion and development of the bug we need to think about how it will be used for more static information that we want as reference material. We could specify a link to specs in the wiki using a URL in the URL field, but there is only one such field. We could also specify custom fields for the spec. The idea being that this link is available in scrumbugs.
  • Feature branch. Similarly to the need for a link to specs there is a need to link to a feature branch. A custom field could achieve the same.
  • Unclassified bugs. This is just a bugzilla report but we would want to get a list of all bugs that have not been classified for scrum.