search

mozilla / scrumbugz

Scrummy look at Bugzilla data. Discuss in #scrum on irc.mozilla.org.
http://scrumbugz.rtfd.org
Other
32 stars 20 forks source link

Restore sprint management in Bugzilla whiteboard data? #89

Open lmorchard opened 11 years ago

lmorchard commented 11 years ago

I haven't been following Scrumbugs development. But, unless I'm mistaken (which I well could be), it seems like scrumbu.gs stopped reading the whiteboard on bugs for things like sprint & points.

Is there any way to get this functionality back? I hear that it's all managed under admin in scrumbu.gs now, but I don't have admin access (and don't particularly want it). So, admins have to manage bugs in two places (ie. bugzilla and scrumbu.gs), and non-admins like me (or contributors) can't do anything to sprints at all.

whimboo commented 11 years ago

Dupe of my filed issue #86?

pmclanahan commented 11 years ago

Points and other story data are still managed in the whiteboard, but sprint is managed on scrumbugz now. The advantage will be that sprint planning features will be good, but we're stuck right now due to some technical hurdles with timely updates from bugzilla. I'm almost done with a version that should solve these issues by getting push updates from bugzilla via email (like bugbot et al) that will keep things updated to within a minute or so of bugzilla.

Moving stories into or out of sprints does seem like an admin job to me. Altering points, components, users, and bug completion state are developer tasks. In our discussions (mostly @bensternthal , @willkg , and I) we decided that moving stories into and out of backlogs and sprints was better handled by scrumbugs because we had more control (anyone in the world could drop a story into or out of a sprint), and we could record movements for analysis later.

I'm certainly open to suggestion if we can come up with a better system that meets everyone's needs.

lmorchard commented 11 years ago

It's the managing sprints that I'd like to see back in the whiteboard. We've typically tweaked that as a team on MDN, adding / swapping bugs on the fly. Sometimes we pull in things from off-sprint while one's in progress, but want to track that it happened in the sprint.

Feels like more "process" and less like "agile" to have to go through a designated admin, and even if I had admin access (which I don't really want, to be admin on yet-another-system, that is) I'd rather scrumbugs just be a view on the data that lives in Bugzilla. Or, I'd even be fine if scrumbugs had a more friendly UI to edit bugzilla data, but wish the data didn't live externally

pmclanahan commented 11 years ago

We should chat about this. I want to make it as useful as possible for you, but other forces have pushed us toward managing sprints in SB. I feel like there's a good middle ground somewhere, but I don't know what it is yet.

lmorchard commented 11 years ago

No offense, but feeling like scrumbugz has gotten very much less useful to us since these changes. Current sprint for us is kind of a mess.

Could you possibly make this a per-project option? eg. Let us go back to managing sprint dates in bugzilla whiteboards, let other forces do it in SB?

openjck commented 11 years ago

Just recording my thoughts from our discussion yesterday.

I think it really depends on how strongly you want to promote best practices. Scrum encourages the team to lock down the Sprint Backlog at the planning meeting and not change it after that. By doing this, the team can predict what will be done at the end of the Sprint with pretty good accuracy. If you want to encourage this, I think it makes sense to only allow someone with administrator privileges (probably the Scrum Master) to change a Sprint Backlog.

On the other hand, our team often changes a Sprint Backlog part of the way through that Sprint. For teams that do that, the whiteboard is much more convenient.

We talked about a per-project option, but even then the question about promoting best practices remains.

Personally, I think Scrumbugs should promote best practices. There are already enough tools out there that could be used for Scrum -- you could do Scrum just using Bugzilla searches for example -- but not enough tools that really enforce the kind of thinking that makes Scrum work.

Just my two cents. I really like that we have so many different people sharing perspectives on this.

openjck commented 11 years ago

One other note.

If nothing else, I think we all agree that it would be nice for Scrumbugs to at least write metadata to the Status Whiteboard. For example, when a bug is moved into a Sprint called "2012-01-01", Scrumbugs could add the following to the bug's whiteboard:

sb-sprint=2012-01-01

This way, we could still make use of that information within Bugzilla (searches, etc.)