most recent 30 from http://fogbugz.stackexchange.com 2012-02-09T13:27:03Z http://fogbugz.stackexchange.com/feeds/question/1821 http://www.creativecommons.org/licenses/by-nc/2.5/rdf http://fogbugz.stackexchange.com/questions/1821/scrum-capturing-sprint-and-build-information Simon Lampen 2010-02-07T04:42:51Z 2011-05-13T18:58:35Z

<p>I am trying model how we are going to use Scrum in FogBugz and combine this with logging build numbers from nightly builds etc. I have been looking at the implementation from Daniel Root <a href="http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html" rel="nofollow">http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html</a>. I would like a way testers and users can easily filter to see what issues or features have been addressed from the previous day's work.</p> <p>So if we use milestones to identity a sprint, how would we identify a specific build in which a feature or bug was addressed? Could we should we use Tags? Perhaps we could create and field using the Custom Field plugin called Build Number? The issue seems that in FB milestone includes the notion of 'Fix For' a nightly build number, a slightly larger sprint, and even a next release product version.</p> <p>A little more analysis has it that: A product version will be the result of one or more sprints (so a parent-child type relationship) An incrementing build number may well fall in this category as well, but I don't think changing the milestone after every build makes sense?</p> <p>Does anyone have any experience with this and could shed some light or offer suggestions.</p> <p>TIA</p>

http://fogbugz.stackexchange.com/questions/1821/scrum-capturing-sprint-and-build-information/1822#1822 Marc Moroz 2010-02-07T19:09:11Z 2010-02-07T20:53:05Z

<p>We use tags and it works great. It's easy to use, lives across milestones, and easily editable. We enter "buildnnn" where nnn is the build number.</p> <p>Just remember that you will want to start with 001 because build1 will also bring up build 10, 11, etc. - Another good way to number the builds could be yyyymmdd.n - example: 20100206.1 (first build on February 6th, 2010. Building them this way also makes it easy if you ever want to sort on the build number.</p> <p>Because you're already in the tag field, it's easy to load it up with other valuable information like - TestReady, NeedsReview, etc.</p>

http://fogbugz.stackexchange.com/questions/1821/scrum-capturing-sprint-and-build-information/8207#8207 Michael Nieminen 2011-05-13T18:58:35Z 2011-05-13T18:58:35Z

<p>This works unless you're using the Release Notes function to generate your release notes semi-automatically. The Release Notes are generated by milestone (e.g. v1.4) and will not work if you're using the milestone to track the sprint name.</p> <p>FogBugz should really support both <strong>milestones</strong> and, separately, the concept of <strong>target version number</strong>. These are not the same idea in many development environments.</p> <p>We are temporarily handling this the opposite way: We use <em>tags</em> to track the <em>sprint</em>, and use the <em>milestones</em> to track <em>target version number</em>. This allows us to generate Release Notes, but unfortunately we cannot use the EBS functions at all.</p> <p>If you are adopting Scrum, as we are, you might be better off checking out <a href="http://www.rallydev.com/" rel="nofollow">http://www.rallydev.com/</a>.</p> <p>Michael</p>