Comments on Daniel Root's Blog: How To: Apply Scrum Using FogBugz 7

I'm applying your suggested method in FogBugz,...

2011-01-21T17:26:55.080-06:00

I'm applying your suggested method in FogBugz, but I'm running into an issue. In my product backlog it becomes non-trivial to see which are the most important issues in a certain project because issues of all project are combined in one backlog (unless you apply a filter of course). Is there a reason why you use a cross-project backlog instead of a backlog per project? Am I missing a fundamental part of the Scrum methodology here?

I am having a series of difficulties very similar ...

2009-08-28T03:25:27.273-05:00

I am having a series of difficulties very similar to Joshk. In house development is a lot more fuzzy, for example I have got 32 seperate inhouse "products" to support and then email etc. however "projects" cut across product boundaries, and the reporting "upwards" issue is a big thorn in my side - I have written tools to extract tasks from bugz and push into MS Project or taskjuggler, none of which entirely satisfies.

I would be very interested in seeing how others tackle this - for some reason the conceptual light has not come on.

A gnarly bug could also be considered a 'Proje...

2009-08-17T19:12:20.869-05:00

A gnarly bug could also be considered a 'Project', even though it is not technically a 'Feature'.

FogBugz really does a great job organizing developer tasks. However, move up the food chain a bit and we're better off aggregating the data in some other tool.

I could probably figure out a 'do this, not that' work around for what we need, but it would be very hard to maintain at production speeds.

At first this gave me pause, but the more I though...

2009-08-17T16:51:00.477-05:00

At first this gave me pause, but the more I thought about it, it's really a matter of 'what is a project' vs 'what is a feature'. In our consulting company, it's pretty clear what a project is: we have a contract for each one :) In your situation, though, I could see it being fuzzier. What management calls a "project" may well be a complex "feature request", and therefore just a case w/ subcases as you describe.

The only other thing I could see doing would be to write a plugin. It wouldn't be too difficult, but it would be another project. Or feature request... :)

I have, but it looks a bit buggy right now. I pla...

2009-08-14T10:04:18.904-05:00

I have, but it looks a bit buggy right now. I plan on adding something similar, but just using the custom fields plug-in.

The company I work for (wink) wants to start using FogBugz as a full blown project management tool.

My biggest issue right now is how to organize things so I can get a big list of projects and their estimates for management. They tend not to care about the millions of individual cases floating around.

I'm thinking I can setup each major project as a top level case and make all the real work sub-cases underneath. This way management can see the status of projects quickly. They can then order these high level projects using the Backlog plugin.

Some limitations with this method, but it's the only way I know to create a priority sortable list of projects.

Thanks Josh! Sounds like a good flow, definitely s...

2009-08-14T05:44:32.960-05:00

Thanks Josh! Sounds like a good flow, definitely seems to work well. Have you all looked into the Kanban plugin for FB7? http://www.fogcreek.com/FogBugz/Plugins/plugin.aspx?ixPlugin=15

We have been doing something similar for a while. ...

2009-08-13T12:52:02.422-05:00

We have been doing something similar for a while. We don't do full Scrum, but it's close.

Our testing team tends to work on a seperate schedule than our dev team, we have to compensate for this.

As a result, we have two milestones 'Web Dev Cycle'(Dev Sprint) and 'Web QA Cycle' (QA Sprint). We have a weekly handoff meeting that moves cases from Dev to QA. If a case is reopened due to a bug, we can clearly see that it is holding the release because it is a 'Web QA Cycle' case, not a dev case.

What ends up happening is that the two cycles overlap a bit.

Monday

10:00 AM - 10:15 AM: “Cycle Progress” meeting

All day: Developers working on next release and fixing bugs in current release.

All day: QA working on current release.

Tuesday

All day: Developers working on next release and fixing bugs in current release.

All day: QA working to move current release to production.

Sometime: Site released to production.

Wednesday

9:00 AM - 9:30 AM: “CS Weekly Top 10” Meeting

10:00 AM - 10:30 AM: “Cycle Progress” meeting

All day: Prep for next cycle (department meetings, new bug data gathering, retrospectives, etc)

All day: Developers finalizing next release

Thursday

9:15 AM - 9:30 AM: “Dev to QA Code Handoff” meeting

10:00 AM - 11:00 AM: “Management Priority” meeting

1:00 AM - 2:00 AM: “Next Release Task Assignment” Meeting

Afternoon: Developers working on next release and fixing bugs in current release.

Afternoon: QA working on current release.

Friday

All day: Developers working on next release and fixing bugs in current release.

All day: QA working on current release.

“Cycle Progress” – Discuss current progress, any issues or questions, last minute changes, and drop tasks that won’t make code freeze.

“Dev to QA Code Handoff” – We call this “Code Freeze”. Discuss release details, QA questions, database changes, and any other info important for testing.

“Management Priority” – Discuss new issues and priorities.

“CS Weekly Top 10”– Discuss top 10 customer support issues and possible solutions for next web release.

This has been working fairly well.

Thought I would share.