Page MenuHomePhabricator

Identify features Scrumbugz users would miss in Phabricator
Closed, ResolvedPublic


Scrumbugz is a way to manage Bugzilla tickets. It is being used by the Wikidata Developers team at



Event Timeline

flimport raised the priority of this task from to High.Sep 12 2014, 1:31 AM
flimport set Reference to fl222.

qgil wrote on 2014-04-26 19:06:07 (UTC)

Ok, so it seems that Scrumbugz allows you to define a team (aking to a Phabricator project) and list tasks (mapped to Bugzilla reports) for it:

Then, you can select tasks (Bugzilla reports) for a specific sprint, and Scrumbugz will offer you a table of tasks for that sprint, plus scrum stats and graphs to follow the progress:

Today you just create projects for sprints in order to track the tasks specific to that sprint. There is a plan to create different types of project (including sprints) at

When it comes to tabular data, Phabricator may probably provide just the same. However, Phabricator relies more on project boards than on burdown charts.

As far as I'm aware, the Wikidata team is the only one using Scrumbugz. Looking at the history in the site, it looks like they are using it since March. With a Scrumbugz-based process so young, what are the main pain points you see in an eventual switch to Phabricator? Apart from the Bugzilla migration, which is discussed at T39: Set up permissions for Phabricator.

aklapper wrote on 2014-04-28 08:26:48 (UTC)

On first glance, Phabricator's agile tools implementation is very limited.

The items in that paragraph are probably worth separate tasks in this Phabricator instance, so we can track them (and potentially upstream them when wanted) plus discuss more focused with members of other Wikimedia teams doing agile development.

qgil wrote on 2014-04-28 13:08:34 (UTC)

Yes, agreed, specific subtasks are welcome and very useful to organize our requests to Phabricator upstream.

T44: Migrate Bugzilla attachments to Phabricator also contains missing agile/scrum features, and Trello users are relying on additional tools to organize their agile development. In order to organize all these features under a common umbrella, there is now T238: New task comment dropdown is confusing.

qgil wrote on 2014-04-29 01:09:04 (UTC)

Many of your requirements are supported by Phabricator, and the rest is defined now at T244: Configure inbound email for

The Maniphest reports do not show the task points.

Minor detail, but the plan is to show custom fields at some point, see and

If there is something still missing, please speak up.

chjohnson wrote on 2014-04-29 08:46:33 (UTC)

It should be emphasized that Scrumbugz only exists because of the limitations of the current Bugzilla-centered workflow. And, it is entirely dependent on Bugzilla. It simply allows the Wikidata team to manage and implement scrum logic on the tasks generated and updated with Bugzilla. Though new in implementation, it has proven to be quite useful.

Its utility is inversely correlated to the disorder that is the result of receiving a high volume of email bug updates on a daily basis. As a tool to readily order and view these updates, by segmenting "active sprint" bugs from backlog bugs, Scrumbugz enhances the limited product/component management functionality of Bugzilla. Furthermore, it allows the consolidation of the incorrectly identified and/or deprecated product/component namespace partitioning of Wikidata relevant bugs.

Scrumbugz is a convenient way for the team to implement agile methods, like points estimation and burndown charts. It should be noted that the Scrumbugz burndown chart is a nice feature. At one glance, it shows what is happening or not happening with the sprint. This kind of application simplicity is valuable, because it saves time. Additionally, before we implemented Scrumbugz, points estimation was not a key part of the sprint planning meeting. It has since, however, become a simple method for the team to cooperatively discuss the relevance of sprint items.

On first glance, Phabricator's agile tools implementation is very limited. There is no burndown chart. The project workboard seems to just be a hybrid Maniphest view. The Facts graphing application seems underdeveloped ( The Maniphest reports do not show the task points. The Maniphest burnup chart shows task completion as a burnup rate, but not at all related to points. At this stage in development, I would say that Phabricator cannot match Scrumbugz in its basic implementation of agile.

chjohnson wrote on 2014-04-29 09:23:56 (UTC)

External tools support:

The Gerrit Notification Bot ( uses Bugzilla's XMLRPC interface as does Scrumbugz. Bugzilla has a robust API. (

Phabricator's API implementation is limited to Conduit. According to the Phabricator developers, Conduit "is unstable and incomplete so you should keep your expectations very low if you choose to build things on top of it"

qgil wrote on 2014-04-29 13:13:27 (UTC)

@chjohnson, Gerrit Notification Bot is used to communicate between Gerrit and Bugzilla. No Conduit is needed to communicate between Differential and Maniphest within Phabricator, therefore this is not a feature that Scrumbugz users would miss in case of migration.

@thiemowmde, please post your comments in the appropriate tasks in order to keep the conversation useful. See T47: Clicking "Edit" on your own Maniphest task comment appends a comment instead of editing the existing comment, T229: Catch up on CX work, T37: Migrate Mingle data to Phabricator, and/org dependent tasks. Thank you for your feedback in any case!

thiemowmde wrote on 2014-04-29 14:22:26 (UTC)

Edit: I posted to the wrong thread. Sorry. I moved my comments to other tasks.

qgil wrote on 2014-05-01 14:23:42 (UTC)

Alright, so it seems that T244: Configure inbound email for contains the features that would be missed by Scrumbugz users. If you find more features missing, please create new tasks for each. Resolving this task.