(this is distilled from of
ZenAndXpTracking. See the bottom for contributors)
Introduction
To use this plugin, you have to care about your project progress status.
That is, you have to be willing to:
- Devote some initial time in the set up of you project and teams. It will take about 20, well spent, minutes;
- Formalize the iterations, stories and tasks that lie ahead, which is a good practice anyway;
- Update regularly the status of each task, or more reasonably make your team aware of the need for each person to update the status of his/her own tasks.
What you gain, in turn, is a set of gauges that very quickly keep you updated on the overal and detail status of your project.
When compared to other project management products, this plugin has several advantages:
- Extremely simple and lean.
- Promotes the team awareness of the project status.
- Give the team a sense of ownership on the tracking, as the actual tracking is not done by some abstract individual that is not part of the team (read: Projet Manager)
- Allows to have a complete journal for each activity.
- Uses a very well known and natural methaphor of green is good and red is bad to catch with a glimpse the status of an iteration.
- Focus less on planning and more on steering, so is good to use in the day to day.
- The info is available to anyone that can access the site.
- And last but not least, it's FREE.
Its main disadvantage (which prevents the complete buyout from the PMs) is that is doesn't focus on planning in the traditional way. But, after all, this is an
XpTrackerPlugin so if you're using it then you don't plan in a traditional way
The typical organization
The plugin makes some assumptions on the organisation that is to use the tool.
Projects
The plugin assumes you want to keep track of multiple
projects in the same web.
You don't have to necessarily be managing multiple projects to use the tool, but the structure of the tool starts with a
list of projects, to allow this eventuality.
You can have a single project per product, or a project per product release.
Teams
These projects, in turn, will be divided among multiple
teams, all cooperating to the same effort, to implement the same project.
These teams are nothing but a way to group Iterations. Most of the information in the Project and Team page is redundant,and if you only have one Team the information is the same.
It's not possible to assign the same Team to more than one Project.
Iterations
Each team, in turn, will be involved in a series of
iterations, that is in Xp the basic period for detail planning.
Strictly speaking, an iteration is a fixed period of time during which a fixed amount of work will be done. As any team can customize the process to fit its needs,
XpTrackerPlugin allows to have several iterations with different duration. Also, you can map Iterations to Development Phases is you want.
Another option, that is strongly discouraged, is to use one iteration per product release. Don't do that. Trust us.
Web set up
First and foremost, install
XpTrackerPlugin, and all the associated plugins (
EditTablePlugin,
TablePlugin). When you install
XpTrackerPlugin, a web named Tracking is created with all the files needed to track a project.
Now you need to decide your webs structure: Will you have one web to track everything, one web per product or one web per project?
Now, create all the webs you will use and copy the content of the Tracking web to each one.
Then make sure the lock on pages is released immediately after topic change, to avoid incorrect behaviour of the
EditTablePlugin when you try to modify a table of a topic that is left locked.
Just copy
* Set RELEASEEDITLOCKCHECKBOX = checked = "checked"
in the web
WebPreferences of each tracking web.
Start with the first project
In the first page the only variable used is
XPSHOWALLPROJECTS.
This displays the list of open projects, and a form to add new projects. From this point, the creation of pages is recursive, each page has an HTML form that uses a template to create child pages.
The project
The meaning you give to projects depends on your organization. The most common choices are:
- One Project per product
- One Project per Product Release
Use the form to add a new project. The project name doens't have to follow a particular naming convention, as long as it is meaniningful (it helps

) and it is a
proper WikiName. Note the name down, as you will have to enter it manually in some pages down the line (as I understand it, due to TWiki design parameters are not passed over automatically any further than the first link)
To add the project simply preview and save the template. The information in the template contains most of the aggregate information needed to monitor the project from a high level. You can always add your own information on a later stage, or modify the template to suit your needs once you get aquainted with
XpTrackerPlugin, but for now accept the defaults.
The tables in this page will appear empty, until you have defined the first story and started defining tasks in the story. This is by design, don't worry and keep setting things up.
The Team
The next step is to add one or more teams. To do that simply use the form in the project page to add a new team, and as for projects the name doens't have to follow a particular naming convention as long as it is meaniningful and it is a
proper WikiName.
Again, simply preview and save the template, accepting the defaults for now.
As said earlier, a team is a way of looking at a part of a project (groupsof Iterations), and a way of organising the reports. There is little need to add information in this page, at least at the beginning.
Keep going with the setup, you need to enter some more information before you see data popping up in those tables!
The Iterations
You create iterations from the form in the team page. Again the name doens't have to follow a particular naming convention, as long as it is meaniningful and it is a
proper WikiName.
It helps to use a sufix for iterations, like
Phase or the less creative
Iteration, like AnalisysPhase or PrototypeIteration so the iteration topics can be easily remembered and the names don't collide with non-iteration topics.
Iterations contain some more information, in the summary table, that you should start filling in. No field is mandatory, but they're useful to fill.
The Summary field is used to describe the iteration, and the Start and End Date fields are used to sort the iterations from the most recently started to the first started. Also, these fields are shown in the iterations summary in the team and project page.
In the Iteration page you'll find a sortable table with the status of all the Stories that belongs to it, and at the end of the page there is a sortable table with the loads and velocities of each developer. The sorting in both tables is done at the client side, so no reload from the server is needed.
The Stories
Time and effort information is inserted in the story page by way of tasks.
You create stories from the form in the iteration page. This time the name
has to follow a particular naming convention, namely it must be a useful and
proper WikiName, ending with the word
Story. This is a mandatory condition, as it is the only way the plugin is able to fetch and parse stories.
A Story can be a single requirement, a Use Case or simply a Story in the Xp sense. Your choice.
Again, as in iterations, the page contain some more information, in the summary table, that you should start filling in. The most important field is "Story Summary", that will be shown in the iteration page.
In the
Next Story field you should put which story to implement once this story is finished, to stablish an implementation order. If you want to rearrange the order, just change the
Next Story field.
The
Story Lead field indicates who is responsible for this story (even if he's not the one implementing it)
The
FEA field is used to track the story to some requirement document, ticket number or bugtracker number. Just put there there reference and that's it.
The
Passed Acceptance Test field can have the following values:
- No: The story has not been tested yet.
- Yes: The story passed the test.
- Error: The story didn't pass the test.
- On Hold: The story was put on hold and is not being developed.
- Deployment: The story implementation is being put in the server for acceptance.
The only important values are
Yes and
No, you can ignore or change the meaning of the others to your heart content.
To move a Story from one iteration to another (in the same web), just change the value of the field Iteration. To delete an existing Story, change it's iteration to "TornUp"
Tasks
TODO
How to get information
The iteration status page displays the stories and tasks currently allocated to that particular interation.
Stories are displayed in the order in which they are to be developed, with the original story estimate following the story name. The story is initially displayed
with a green background, which changes to blue when complete and awaiting acceptance testing, and to white once the story has been successfully
acceptance tested.
Tasks within a story are displayed in the order in which they are to be developed, initially with a pink background, which changes to white as each task is
completed. Tasks are considered complete once their estimate until completion is 0 days.
What is measured
This is a list of tables that can be produced by the plugin. For each table, you will find the variable name to produce it together with the eventual parameters, a technical description of the information provided by the table, and where the variable is currently placed by the templates.
XPSHOWALLPROJECTS
- Parameter : none
- Default location : by itself in a startup page
The table created has no particular information: it simply lists the names of all defined projects, and it is used as root to start traversing the project structure.
Besides creating the table, the variable offers a form to insert new projects
XPSHOWALLTEAMS
- Parameter : none
- Default location : doesn't have a default position
Identical to XPSHOWALLPROJECTS, except that the table contains a team column. It is not present by default in any page. One could substitute XPSHOWALLPROJECTS with this variable in the main page.
Besides creating the table, the variable offers a form to insert new
Projects.
XPSHOWALLITERATIONS
- Parameter : none
- Default location : doesn't have a default position
Composes a table with the name of all projects, teams and iterations, plus a summary for each iteration.
It is not in any default template and I honestly fail to see the use for it.
XPSHOWPROJECTTEAMS
- Parameter : project name
- Default location : Project page
The table is used as project root, and offers a bare list of team names only ofr the teams working in the project.
It is particularly handy to call it from the project page, as the project name is also the topic name, and you can use the
XpTrackerPluginManual variable.
Besides creating the table, the variable creates a form to insert new teams
XPSHOWPROJECTITERATIONS
- Parameter : project name
- Default location : Project page
This variable creates a table containing summary information on all iterations for the project.
The table doesn't merely display information from the Iteration details table, but actually composes summary data from all tasks that compose all stories for each iteration.
It is possibly the single most useful table, especially if you are interested in the bottom line of how many days it took to get at present state and how long it will take to completion, and it deserves the first position in the project page, as it calculates days estimated, spent and todo, and it diplays percentage progress, using both the percentage and a simple and clear red and green gauge.
One final information is the overrun, in the form of a percentage between the sum of time spent and left to do, and the time that had been estimated.
Rows alternate a white and yellow background, but no information is attached to this colouring.
No total is given for all iterations, but that would probably be too vague a figure, anyhow.
XPSHOWPROJECTCOMPLETIONBYSTORIES
- Parameter : project name
- Default location : Project page
Compose one table, listing per each Iteration summary stories information, such as the number of total stories, and how many are not started, in progress, completed and accepted.
Finally it gives the bottom line of percentage of accepted stories, per Iteration, but with no red/green gauge!
Rows alternate a white and yellow background, but no information is attached to this colouring.
XPSHOWPROJECTCOMPLETIONBYTASKS
- Parameter : project name
- Default location : Project page
Compose a table, much similar in structure to the previous XPSHOWPROJECTCOMPLETIONBYSTORIES table, but giving per each Iteration summary information on the tasks status.
Rows alternate a white and yellow background, but no information is attached to this colouring.
XPSHOWPROJECTSTORIES
- Parameter : project name
- Default location : Project page
This variable actually composes two tables, listing all completed stories for the project, with their completion date, and all uncompleted stories.
Rows alternate a white and yellow background, but no information is attached to this colouring.
XPSHOWTEAMITERATIONS
- Parameter : team name
- Default location : Team page
It composes a page identical in structure and content to the one composed by XPSHOWPROJECTITERATIONS, but limited to the Iterations assigned to the team.
It gives the team manager the same information that XPSHOWPROJECTITERATIONS would give to the project manager, if the two roles are distinct as in the case of large projects.
Rows alternate a white and yellow background, but no information is attached to this colouring.
XPSHOWITERATIONTERSE
- Parameter : iteration name
- Default location : Iteration page
Composes a page
similar in structure and content to the one composed by XPSHOWPROJECTITERATIONS. The difference, besides the fact that it is organised per story and it lists all stories composing the iteration, lies in the fact that this time row colours convey a specific information.
The story is initially displayed with a gray background, which changes to green when complete and awaiting acceptance testing, and to blue once the story has been successfully acceptance tested.
XPSHOWITERATION
- Parameter : iteration name
- Default location : Iteration page
Composes a table listing tasks grouped by stories. Tasks within a story are displayed in the order in which they are to be developed, initially with a gray background, which changes to green as tasks are in progress and white as each task is completed. Tasks are considered complete once their estimate until completion is 0 days.
Stories summarise information on estimated, spent and remaining days, and have the same colouring as in XPSHOWITERATIONTERSE.
XPVELOCITIES
- Parameter : iteration name
- Default location : Iteration page
Compose a page summarising per each developer the days (called
ideals ?) and tasks assigned, spent and remaining for the particular iteration.
The bottom row in the table shows summary overall days and tasks.
XPDUMPITERATION
- Parameter : iteration name
- Default location : doesn't have a default position
Use this variable with sense, as it basically prints in one single (huge) page all information about all stories and their tasks for the iteration!
How to keep the information updated
Each developer should be in charge of each task, once the task has been defined in the planning stage.
To stick to XP, you should actually let the developer
- take responsibility of the single task (auto assign the task),
- estimate the time required,
- update the progress accordingly.
You can decide, depending on your organisation, how much to let him/her do, but I assume you would at least leave each developer the progress update.
Alternatively, you can designate a Tracker who will be the sole responsible of updating the tasks.
The choice is, as always, yours.
Contributors (in no special order):