This page is for the Scrum specific discussion of ZwikiAndProjectManagement.

DeanG's notes, philosophy, what-not-kick-off.

Preface: I don't like task management. I like feature and issue management and feel that any knowlege workers measured or estimated below 1 hour granularity is a waste of time. Task management leads to micro-management which erodes autonomy, ownership, inspiration... I have yet to see metrics implemented successfully beyond item counts over time-and in this context issues.

I feal Features and Issues/Bugs/Anomalies should be managed seperately. The former (should be) an Asset, the latter a Liability. When theres debate whether the effort in correcting a new found issue constitutes a new feature and it's best managed as a feature, then [make the decision--move on] manage it as a feature.

I like the simplicity of ZwikiIssueTracker. Most extra information can be added in the "memo" field. So far, in my experience, adding fields isn't simple (mostly tedious) but possible.

I haven't researched Feature Driven Development.

I may be abusing the needs of a "Product" wiki, and a "Project" wiki. Requirements mgt., PMI, Action Items, Check-lists and other list and mgt. items are out of the scope of this discussion and can be discussed at GeneralDiscussion or ZwikiAndProjectManagement. Why? The beauty of IssueTracker is that its simple (almost vague) ready for self-interpretation by the implementors. Scrum, as it's a framework, also has this facet. Many Agile Methodologies can be implemented, or even mixed together, under Scrum.

If you need a complicated tool, use one of the many overfull-featured management systems and bind them all with a good search appliance.


I would like to build a FeatureTracker?, and thus remove the wishlist category in IssueTracker.

Fields of a Feature: id, Description, Goal name, Developer Contact, Customer contact, Estimated Effort, Current Effort, State. (Created, Edit and Memo fields are also included but inherit in Zwiki, like IssueTracker.) Possible: Due Date.

The only selection field would be State: Planning/Refining, Designing, UnitTesting?, Coding, SystemTesting?, Fixing, Done. This needs to be as dynamic as the IssueTracker's categories. For example: Should "Documenting" be an item?

Goal field. This field represents an associated page in the Tracker.

How does this fit into Scrum:

This is represented by a Goal.
Daily Status
Fields are updated manually. (Current Effort may have a specific "add time" form in the Feature page for ease of use.) The Sprint status is updated daily via an initiated process [for each goal] which adds accumulated totals to the specified Goals page, or potentially that GoalsStatusData page. This data could be processed internally to produce a chart, or copied/pasted into an external charting tool. (Excel, etc.)

Burn Down Chart - The data for this could be derived from each GoasStatusData page, or a FeaturesStatusData.


I'm out of time. I'll review my notes and add more later. :-) Please add comments anyway.

feature tracker comment --FlorianKonnertz, 2003/04/18 15:45 GMT
An own feature tracker is a good idea. I use the IssueTracker for bugs and features and if i add a feature which i want to realise soon i set severity to ie. serious, which is of course an abuse of this field. :-/ But it never came to my mind to create just a second instance of the tracker for features only, i guess because i want to have everything under one hat, manage it from one point. - Question: Any ideas if both trackers could interact somehow? (I don't have a concrete idea - maybe just link from a bug issue to the related feature issue??)

I don'r remember scrum at the moment, have seen it some weeks ago (thx Dean), i'll have a look again. - Just wanted to add a quick comment now. - One more thing: I like feature and issue management and feel that any knowlege workers measured or estimated below 1 hour granularity is a waste of time. - Yeah, that's it! Keep task management as light as possible! - FloK

- --WimBekker, 2003/04/18 16:11 GMT
This looks promising. Although Fields are to be updated manually, there should be very little fields to update to kill overhead. A lot of the fields can be calculated by the program (or web or how do you call it?). I like the Fields of a Feature. I think I would use some extra, but a lot are autocreated. A Burn Down Chart should also be autocreated.

For my company I already split features and issues. Issues take precendence over features and probably can/will stop a pending Sprint (yet we have to start with Scrum though). Probably we are going to use several Sprints followed by a Release Sprint.

Joining in... --PieterB, 2003/04/18 16:54 GMT
I had a look at and I must say that it looks really nice. Any Zwiki people interested in having a trial (mail me your e-mail, and I'll add you as as user. My email address is listed on PieterB). Maybe a Zwiki version would be very nice. It might also use/integrate with CMFCollectorNG? (which will be used in Plone in future).

Task management etc. --PieterB, 2003/04/18 17:41 GMT
I don't think task management is often used, but I think a bug/feature/issue system should have an option to manage the estimated length of an issue recovery. I don't think Features and Bugs should be managed seperatly. Features and bugs are both issues, which need to be resolved/managed.

I can imagine that some bugs depend on features. For example the "bug" "Zwiki doesn't run on Zope3" can only be closed if the "Zope 3" feature is implemented.

More fields: Assigned-To, Category, Fix-for-release, Priority, Estimates (original, current, elapsed, remaining), data specific for the project (e.g. Zwiki-Version, Zwiki-platform, etc.).

Maybe we can use the ArcheTypes? for this kind of tools.

- jshell --2003/04/18 19:48 GMT
One thing I've learned over my long painful search for a simple, fast, usable, configurable, etc, issue tracker is that having ONE tracker is much better than having MANY. much much much better. We used to divide trackers/collectors up into individual projects. But as certain projects started to depend on the same core software, entries were getting lost as the person watching for entries was watching a different collector than the one adding new ones.

If you can keep issues within the same collector but have different (but similar) classes, it makes things nicer. The Fresco Issue Tracker at keeps Bugs and Tasks in the same collector. A "Bug" entry has to do with a problem with existing code. A task covers anything else. A separate Milestone object is used to group certain tasks and bugs together that are scheduled to go into a milestone release. In house, we do something similar (but with just a single issue class), using Projects to group Issues and other objects (such as documents) together.

A long time ago, Zope Corp had two separate collectors for Bug requests and Feature requests. There were slightly different fields between the two (and they were written with the archaic Tabula software). One of my fairly early tasks at the company was to join the Two into One. It was painful. Even more painful was how long the resulting system was used (all the way until went KABOOM!). :)

Anyways, another interesting thing about the default Roundup setup is that features, bugs, etc, are just priority levels on issue objects. From lowest to highest, its priority levels are "wish, feature, bug, urgent, critical". Of course, all of this can be customized...

FogBUGZ --DeanGoodmanson, 2003/04/18 22:10 GMT
Does this have much to do with Scrum? Or is it more ZwikiIssueTracker or ZwikiProjectManagement? related?

Bugs, Features, Tasks --DeanGoodmanson, 2003/04/18 23:12 GMT
Tasks - Why I consider this off-topic: A product ships with a Feature and Open Issues list. Tasks are implied responsibility which need to be tracked on paper in a project scenario, and I've only found that hyper-conventient and personal mechanisms work for this-rarely formalized in a specialized. Perhaps this is a good way to discern between Product management and Project management. shrug Not that "gathering a bill of materials" isn't a worthy "Ship 1.8"! Sprint goal, but adding each signature on the "Cover Art for version 1.8" feature would be a task trustable to the Cover Art feature/facet/whatever responsibility holder. (Eek, I smell workfow--another thing best trusted to the responsibility holder: Implementation. (And their tool of choice.))

>> For example the "bug" "Zwiki doesn't run on Zope3" can only be closed if the "Zope 3" feature is implemented.

To me that Issue would be deleted and a Feature would be added. (Since that features so broad it could probably start with a 1 to 1 goal page, and broken into more features as that need was determined.)

I have more thoughts which currently in my head sound like a Scrum sermonette, and I'll try to post as brief as I can later. :-)

J. Shell - Thanks for your feedback. I'll add more later. In the meantime, could you give me some insight into how this page is gathered/developed?: I consider this a Goal page, but not necesarily a Scrummish one (too long of time-frame for a realistic Sprint).

RoundUp? sounds like a wiz-bang tool. Defenitely a next step after outgrowing a's two hopes for the re-Zopeintegration working well within a Plone environment. Wonder what Richard thinks of Scrum. Is he strict on any particular Agile methodologies? Uh-oh, veering more off topic.

FloK- I'm not talking about an IssueTracker used as.. I'm talking about following that model and building a brand new page type. They can be integrated as they are both in the same Wiki, but not to the extent as J.Shell noted. Perhaps that's too much for a lone Zwiki, but having lightweight product & project documentation integrated with the IssueTracker and FeatureTracker? is a nifty thought.

I appreciate the thoughts on making an IssueTracker scale to that level, but wonder if it's Scrum enough. A Scrum vagueness is it's ambiguous treatment of Issues. It's time-boxing, focus scoping and protection, and multi-faceted acknowlegement of features are why I'm captivated and feel that the current IssueTracker doesn't fare best for Scrum (or general?) feature tracking.

Thanks a lot for the feedback. Made for an energizing holiday. :-) I wrote too much to be trusted to a 3 line comment window, but I must eat supper instead of let it rot in Word until it becomes irrelevant. ;-)

!Scrum book, future of a Zwiki/Zope3/Roundup/Plone/CMFTrackerNG? IssueTracker --PieterB, 2003/04/19 11:10 GMT
--PieterB, 2003/04/19
I don't know much about Scrum yet (planning to buy the Scrum book Agile Software Development with Scrum next week). Is this the best book on Scrum?

As I see it FogBUGZ combines planning with issue managing. Both the developper and the project leader can see the amount of time that is expected to be needed for the next milestone/release/bugclosing/etc. I think a feature management system needs some kind of time management (and let's not debate whether the granuality should be hours, days, or years).

I think it would be great to have some Zope tool which would integrate with development methologies like Scrum or XP. I think that there will be some added features for open source projects (e.g. if somebody has a feature request but no projectmembers is willing to work on that feature, the feature should be closed with the status "no commitment to implement"). I think the number of open issues should be moderate, so that it's possible to browse through them.

I think it would be great to see if something like this can be made on top of Zwiki and/or Zope3. I'm willing to contribute to this discussion (as some of you know I'm not a real coder).

Scrum book post response --DeanGoodmanson, 2003/04/20 22:53 GMT

>> I don't know much about Scrum yet (planning to buy the Scrum book Agile Software Development with Scrum next week). Is this the best book on Scrum?

It's the only book specifically on Scrum. If you want an overview of many Agile methodologies (including Scrum) Agile Software Development Ecosystems (BookLookup:0201760436 ) may also work bit is a bit more $45.

The beauty of a Scrum "Sprint" is that the feature list can be huge without overwhelming "need to do all things" because the priorities/features are reviewed the a small set in a small time frame are chosen and focuses upon. Features and issues that show up are deferred until the end of the Sprint (Issues are the grey area here that requires a "Zen of Scrum" type of explanation.) The goal of a limited number of open objectives is met without having to try to define what open or closed means.

(Aside: Not sure what defines a "real" coder or not (interesting stuff about that at the WikiWiki:RealProgrammer ,btw), but happy that you join in discussions regardless of your coding contributions.)


... --PieterB, Mon, 25 Aug 2003 15:31:19 +0000 reply
See my Scrum thread (reply to Chi-web) at or

Scrum wiki --DeanGoodmanson, Tue, 11 Nov 2003 20:58:41 -0800 reply
UseMod? modification to support some of the major Scrum features: