Task Cards On Wiki

Is anyone managing Tasks and TaskQueues? on Wiki instead of on IndexCards or Whiteboards?

Instead of a TaskCard on IndexCards, we use WikiPages with a reference to CategoryProjectName, TopicTask, and TopicIterationN at the bottom of the page. The rest of the page looks just like a typical TaskCard except that it may also reference that UserStory page that it was derrived from.

While not as convenient as IndexCards, it does have its own set of advantages. If we want to see a list of all tasks in a project, we simply go to the TopicTask page and press its title. To see all the tasks in the 2nd iteration, we go to the TopicIteration2 page and click on its title. To see all work in all iterations we just go to the TopicIteration page since pressing its title will match the pattern TopicIteration[*]. When a Task is completed, the person who claimed the task changes its reference from TopicTask to TopicTaskDone. Going to this page and pressing its title shows all completed tasks. Its great to be able to go to a Completed Task Page such as MakeResponseSchedulable and add a reference to RefactorMakeResponseSchedulable to create a new page for a Task that improves on the original task.

Tasks start out with out any owner. When you are done with your current task, you can claim a new task. This is done by creating a reference to their WikiName in the text of the Task they want to perform. This process is called claiming the task. This also allows one to list all tasks a particular engineer is working on by searching on their WikiName and the TopicTask.

While I'm not completely happy with this method, it does seem to work very well, encourage collaboration, and provide project status visibility to all stakeholders. We also make all our UserStories WikiPages. Instead of TopicTask, the UserStory pages reference TopicStory. We then create the tasks for each story in the story page by creating a new WikiName for the task (anywhere in the story page) and then pressing its question mark to make the WikiName a TopicTask WikiPage. This way, each story references all the tasks it has produced. These new pages are only created as the tasks are thought of.

--RobertDiFalco

I am doing something similar. The problem we faced was having to arrange the cards at meetings, and the fact that only one person can hold the actual cards (we are not doing true XP, and are not all at the same location, except for meetings). By having them on our Wiki, we all have easy access, and we pull up the actual pages during our meetings (we have networked computers connected to projectors in certain meeting rooms). During the meetings we move things around, add text, and assign action items. It is not as fluid as paper, but at the end of the meeting, the Wiki is up to date. -- RichardBash

We started out using Wiki for project relevant information, e.g. stakeholder contact details, Todos, software information, tips and tricks .... all the kind of information that would normally be gotten from the TruckNumber-person, i.e. TruckPerson?.

Having gotten a rough idea what was to be done, we did a series of scenarios [our terminology for UserStories] on index cards. Once we had a first version, we typed them into Wiki. What we did next was to identify components and sequences which corresponded with the scenarios. Components where described using CRC principles but, for reasons of understanding, the term Object was avoided. The next step was the design of an architecture, this was then also stored in Wiki.

Unfortunately what has now happened is that the stakeholder wants a document .... a Word document -- what we have is a series of HTML pages! But that isn't a problem -- a couple of AWK scripts later -- one large HTML document built out of the various pieces lying around in Wiki, plus the advantage of being able to modify the parts and being able to generate a whole. But ofcourse this document does not match with the company document standard. This problem remains open .....

-- GerritRiessen

ChangeTheStandard?.

CategoryCard