tag:blogger.com,1999:blog-6168885358747558006.post4177783240406755951..comments2023-11-13T02:21:03.550-06:00Comments on Daniel Root: How To: Apply Scrum Using FogBugz 7Daniel Roothttp://www.blogger.com/profile/04004685127300233374noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-6168885358747558006.post-509074318821511982015-04-29T15:18:03.033-05:002015-04-29T15:18:03.033-05:00"most of our customers don't even know we..."most of our customers don't even know we're doing this to them!"<br /><br />Good for you! That's as far as I got and I already know I'm gonna like this. Your customers shouldn't care, shouldn't need to know, and frankly, most orgs. who do think otherwise are probably using fancy phrases and pitches to impress them rather than what one is supposed to deliver -- a quality product. Your products are better for having used this, right?Jade Bondhttps://www.blogger.com/profile/14465766122372707431noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-74107620193913166852012-06-01T16:19:33.666-05:002012-06-01T16:19:33.666-05:00Enjoyed the article, but I have one question. You ...Enjoyed the article, but I have one question. You are using the Milestone feature to break the work into Sprints. So how are you representing releases in this model?<br /><br />For example, although the release notes feature in FB is nice. I generally compile them manually by filtering on the milestone. It feels like you need a higher level grouping for releases if milestone=sptring.John Fuexhttps://www.blogger.com/profile/08626586841750554031noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-49505162632224637242011-01-21T17:26:55.080-06:002011-01-21T17:26:55.080-06:00I'm applying your suggested method in FogBugz,...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?Willemhttps://www.blogger.com/profile/04227985897683373943noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-30322534739406356602009-08-28T03:25:27.273-05:002009-08-28T03:25:27.273-05:00I am having a series of difficulties very similar ...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.<br /><br />I would be very interested in seeing how others tackle this - for some reason the conceptual light has not come on.paulhttps://www.blogger.com/profile/15930839223608865561noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-3476428174553933772009-08-17T19:12:20.869-05:002009-08-17T19:12:20.869-05:00A gnarly bug could also be considered a 'Proje...A gnarly bug could also be considered a 'Project', even though it is not technically a 'Feature'. <br /><br />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.<br /><br />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.Josh Khttps://www.blogger.com/profile/14458872559041649567noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-13627502205745714222009-08-17T16:51:00.477-05:002009-08-17T16:51:00.477-05:00At first this gave me pause, but the more I though...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.<br /><br />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... :)Daniel Roothttps://www.blogger.com/profile/04004685127300233374noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-84617093194376484242009-08-14T10:04:18.904-05:002009-08-14T10:04:18.904-05:00I have, but it looks a bit buggy right now. I pla...I have, but it looks a bit buggy right now. I plan on adding something similar, but just using the custom fields plug-in.<br /><br />The company I work for (wink) wants to start using FogBugz as a full blown project management tool. <br /><br />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.<br /><br />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.<br /><br />Some limitations with this method, but it's the only way I know to create a priority sortable list of projects.Josh Khttps://www.blogger.com/profile/14458872559041649567noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-64315619211815624892009-08-14T05:44:32.960-05:002009-08-14T05:44:32.960-05:00Thanks Josh! Sounds like a good flow, definitely s...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=15Daniel Roothttps://www.blogger.com/profile/04004685127300233374noreply@blogger.comtag:blogger.com,1999:blog-6168885358747558006.post-90965916290342498792009-08-13T12:52:02.422-05:002009-08-13T12:52:02.422-05:00We have been doing something similar for a while. ...We have been doing something similar for a while. We don't do full Scrum, but it's close.<br /><br />Our testing team tends to work on a seperate schedule than our dev team, we have to compensate for this. <br /><br />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.<br /><br />What ends up happening is that the two cycles overlap a bit.<br /><br /><br /> <br /><br />Monday<br /><br />10:00 AM - 10:15 AM: “Cycle Progress” meeting<br /><br />All day: Developers working on next release and fixing bugs in current release.<br /><br />All day: QA working on current release. <br /><br /> <br /><br />Tuesday<br /><br />All day: Developers working on next release and fixing bugs in current release.<br /><br />All day: QA working to move current release to production. <br /><br />Sometime: Site released to production.<br /><br /> <br /><br />Wednesday<br /><br />9:00 AM - 9:30 AM: “CS Weekly Top 10” Meeting<br /><br />10:00 AM - 10:30 AM: “Cycle Progress” meeting<br /><br />All day: Prep for next cycle (department meetings, new bug data gathering, retrospectives, etc)<br /><br />All day: Developers finalizing next release<br /><br /> <br /><br />Thursday<br /><br />9:15 AM - 9:30 AM: “Dev to QA Code Handoff” meeting<br /><br />10:00 AM - 11:00 AM: “Management Priority” meeting<br /><br />1:00 AM - 2:00 AM: “Next Release Task Assignment” Meeting<br /><br />Afternoon: Developers working on next release and fixing bugs in current release.<br /><br />Afternoon: QA working on current release.<br /><br /> <br /><br />Friday<br /><br />All day: Developers working on next release and fixing bugs in current release.<br /><br />All day: QA working on current release.<br /><br /> <br /><br />“Cycle Progress” – Discuss current progress, any issues or questions, last minute changes, and drop tasks that won’t make code freeze.<br /><br />“Dev to QA Code Handoff” – We call this “Code Freeze”. Discuss release details, QA questions, database changes, and any other info important for testing.<br /><br />“Management Priority” – Discuss new issues and priorities.<br /><br />“CS Weekly Top 10”– Discuss top 10 customer support issues and possible solutions for next web release.<br /><br />This has been working fairly well.<br /><br />Thought I would share.Josh Khttps://www.blogger.com/profile/14458872559041649567noreply@blogger.com