TeamForge : Project Home

Using CTF for Agile Development

Plan a product
1. Set vision and high-level strategic goals
  - The purpose of this step is to establish the vision and high-level strategic goals for the product. This is typically led by the product owner or the product executive. Once established, they set the stage for the product backlog. The vision and high-level goals should be clearly communicated to all project members in a central location.
    - Use TeamForge to communicate vision and high-level goals on project home pages, Wiki pages, or in documents in the Documents tool. It is important to be consistent, given the critical nature of this information.
2. Populate the product backlog
  1. Gather requests from users so that they can be transformed into the epics and user stories that will drive the Agile development team. Requests can come from a variety of sources, including user interviews, requirements documents, external systems, emails, cocktail napkins, etc. The process of gathering requirements varies in every organization.
    - Use TeamForge to store raw user request information in Wiki pages or documents in the Documents tool. This information should eventually be associated with epics and user stories to provide context.
  2. Establish target user types for the product so that all subsequent epics and user stories can be targeted for and assessed in the context of particular types of users. In the Agile world these user types are known as personae.
    - Use TeamForge to document user personae in Wiki pages or documents in the Documents tool. One or more personae should be associated with all epics and user stories to provide context.
  3. Create the product backlog that will contain the epics and user stories for the product. If you plan on implementing multiple products in the same TeamForge project, create multiple product backlogs.
    - Use TeamForge to establish the product backlog by creating a planning folder for each product that your are developing in the TeamForge project. To measure the burndown for each product, add start and end dates with a wide range.
    - When TeamForge object IDs (e.g. page1001 or wiki1002) are entered into description text, they become clickable by users. This lets you use the planning folder description to provide links to product overview information in Project Pages, etc.
  4. Enter epics and user stories in the product backlog so that they can be planned for and implemented in specific releases. user stories should be used to describe single user scenarios that can be cleanly implemented in a single iteration. epics should be used to describe a family of scenarios that will be parent to multiple user story children.
    - Use TeamForge to create epics and user stories by clicking the planning folder created for the product backlog and selecting the desired tracker in the "Submit New Artifact In" dropdown. Or, if epics and user stories are created before the product backlog, that planning folder can be assigned later.
    - There are several ways to associate Tracker artifacts with a planning folder, including clicking the folder path icon when editing a specific artifact, using the "Plan For" and the "Mass Update" buttons in the planning folder tree view or the Tracker list view, as well as cutting and pasting artifacts between planning folders.
  5. Prioritize epics and user stories based on their importance to users (and ultimately your business). Priorities are essential in the release planning process as well as assessing whether a release has achieved its objectives.
    - Use TeamForge to set the priority of artifacts by selecting the appropriate priority when editing a specific artifact, as well as using the "Mass Update" button in the planning folder tree view or the Tracker list view.
Plan a release
1. Populate a release backlog
  - Create a release backlog that will contain the epics and user stories for each release. If multiple releases are planned for a product, create multiple release backlogs.
    - Use TeamForge to establish the release backlog by creating "release" planning folders as sub-folders of "product" planning folders. To enable the burndown for each release, add start and end dates.
    - When TeamForge object IDs (e.g. page1001 or wiki1002) are entered into description text, they become clickable by users. This lets you use the planning folder description to provide links to release overview information.
  - Assign epics and user stories to a release backlog so that they can be planned for and implemented in specific iterations.
    - Use TeamForge to assign epics and user stories to a release planning folder by clicking the folder path icon when editing a specific artifact, using the "Plan For" and the "Mass Update" buttons in the planning folder tree view or the Tracker list view, as well as cutting and pasting artifacts between planning folders.
    - Depending on the need, TeamForge supports moving child artifacts into increasingly granular planning folders without moving their parents. For example, an epic can be parked in the product backlog while its user story children are placed into specific release backlogs. This is a key advantage of TeamForge.
  - Estimate the effort for epics and user stories that have been placed in the release backlog. Depending on the specific Agile process, it is often customary to "swag" the required effort before placing epics and user stories into specific iterations.
    - Use TeamForge to set the estimated effort when editing individual artifacts, as well as using the "Mass Update" button in the planning folder tree view or the Tracker list view. Given that work has not yet started, it makes sense to set the estimated and remaining effort to the same value.
    - TeamForge can calculate the estimated, remaining, and actual effort numbers as the sum of the effort numbers from their children. As an example, the effort for an epic can be derived from the effort for its user story children. Click "Sum effort from children" to enable this for each individual artifact.
    - TeamForge assumes (as of the 5.3 release) that all artifacts in a top-level planning folder use the same effort units, otherwise the burndown and child summing will not function correctly. Therefore the project team should establish standard effort units early in the process and consistently apply them to all artifacts.
2. Keep the File Releases tool in sync
  - If you are planning to use the File Releases tool to store build packages for your releases, you should create a "package" for each product backlog and a "release" for each release backlog. Keeping planning folders and packages/releases in sync will reduce confusion between the use of planning folders for planning and the File Releases tool for "fixed-in-release" notes.

Plan an iteration
1. Populate an iteration backlog
  1. Create an iteration backlog that will contain the epics and user stories for each iteration. If there are multiple iterations planned for a release, create multiple iteration backlogs.
    - Use TeamForge to establish the iteration backlog by creating "iteration" planning folders as sub-folders of "release" planning folders. To enable the burndown for each iteration, add start and end dates.
  2. Assign epics and user stories to an iteration backlog so that they can be decomposed into tasks and implemented by the project team. The project team should get together and agree on the user stories that will fit in the iteration.
    - Use TeamForge to assign epics and user stories to an iteration planning folder by clicking the folder path icon when editing a specific artifact, using the "Plan For" and the "Mass Update" buttons in the planning folder tree view or the Tracker list view, as well as cutting and pasting artifacts between planning folders.
    - Depending on the need, TeamForge supports moving child artifacts into increasingly granular planning folders without moving their parents. As an example, an epic can be parked in the release backlog while its user story children are placed into specific iteration backlogs. This is a key advantage of TeamForge.
2. Break user stories into tasks
  1. Create child tasks for the user stories planned for an iteration. Tasks are the discreet development activities necessary to implement the user scenario described in a user story. Tasks can be independently estimated, assigned, and completed, allowing for parallelism.
    - Use TeamForge to create child tasks for a user story by navigating to the user story, clicking the "Dependencies" tab, and selecting the "Tasks" tracker in the "Create Child In:" dropdown. If the tasks have already been created, you make them children of user stories by using the "Choose Child" button, but it is easier to create them for each user story.
  2. Estimate the effort for each task associated with each user story. All tasks for a given user story should fit cleanly within an iteration. As of task decomposition, you will have the most accurate assessment of the effort required for a user story.
    - Use TeamForge to set the estimated effort when editing individual artifacts, as well as using the "Mass Update" button in the planning folder tree view or the Tracker list view. Given that work has not yet started, it makes sense to set the estimated and remaining effort to the same value.
    - TeamForge will optionally calculate the estimated, remaining, and actual effort numbers as the sum of the effort numbers from their children. As an example, the effort for user story can be derived from the effort for its task children. Click "Sum effort from children" to enable this for each individual artifact.
    - TeamForge assumes (as of the 5.3 release) that all artifacts in a top-level planning folder use the same effort units, otherwise the burndown and child summing may not function correctly. Therefore the project team should establish standard effort units early in the process and consistently apply them to all artifacts
Work in an iteration
1. Establish a daily rhythm
  1. Standup meetings are daily team meetings held to provide a status update to the project members. Each team member should briefly specify what they have worked on since the last standup, what they are planning to work on next, and if anything is blocking them from getting things done. Standups should take approximately 5-15 minutes. In addition, this meeting can be used to review progress of the iteration, and highlight the total remaining and estimated effort, as well as velocity for the iteration. After the standup meeting, it is a good idea to document the notes and associate any user stories, tasks, or other documents with the standup notes.
    - In TeamForge, "Open by Priority" and "Open vs Closed" charts are available for every "Iteration" planning folder. In addition, if start and end dates are set, a burndown chart is available that shows daily estimated effort, remaining effort by priority, and an overall velocity for the iteration. Use these metrics as the foundation for daily discussion and course corrections.
    - To keep the project team up to speed on progress (especially on geographically distributed teams), create a new discussion forum for your daily standup notes, and post to it daily. Anyone monitoring the forum will see your updates when you send them. If you refer to TeamForge IDs (e.g. artf1003) in the text, they will appear as links in the Discussion browser.
  2. Update estimated, remaining, and actual effort. It is essential that all of the project team members update their estimated and remaining effort for their assigned tasks (and user stories if they are not summed from tasks) on a daily basis. These updates are reflected in the burndown for the iteration-specific planning folder and any planning folders that contain it.
    - In TeamForge, open the task or user story that you want to update and change the Estimated and Remaining Effort fields.
  3. Find and fix defects. During the course of an iteration, it is inevitable that defects will arise. Product developers and product testers should develop test scripts and run those scripts against user stories as part of test-driven development and continuous integration. When tests fail, defect artifacts should be entered and associated with user story and test artifacts.
    - Use TeamForge to create Test artifacts that track what tests are needed during an iteration. Tests can also be created as children of user stories. Minimally, tests should be associated with any user stories they are intended to cover.
    - Use TeamForge to create defect artifacts that track problems with specific user story implementation. Given that defects are often the result of multiple user stories, it usually makes sense to associate them rather than making them children.
2. Conduct user acceptance testing on user stories
  - User acceptance testing is the process of demonstrating mostly-implemented user stories to actual users, with enough time to provide course corrections based on hands-on feedback. User acceptance testing (UAT) usually occurs during the final stages of each iteration, so that actionable items can be included for the next iteration.
    - Use TeamForge to conduct user acceptance testing by making test builds available in the File Release tool, reviewing user stories in the TeamForge tracker, recording identified course corrections in user story artifacts, and spawning new user stories that can be slotted into upcoming iterations.
3. Conduct iteration retrospectives
  - An iteration retrospective is the process of eliciting team feedback on and making changes as a result of the team's experience during an iteration. The best time to conduct an iteration Retrospective is just before planning the next iteration. During the retrospective, you should document suggestions into two categories, "Things that worked well" and "Things that need improvement." Each team member should participate in adding suggestions to each of these categories.
    - Use TeamForge to record the results of iteration retrospectives in Wiki pages, documents in the Document tool, or as messages posted to discussion forums. They should be visible so that all team members can learn from them.
Deliver a release
1. Package a release
  - Upload the release package to a conspicuous central location that consumers can access in your project workspace.
    - Use TeamForge to upload release packages into the File Release tool (in the appropriate "releases" section for the "packages" that you created to mirror your planning folder structure).
  - Generate release notes based on the epics, user stories, and defect fixes that were implemented in the release.
    - Use TeamForge to generate release notes by relying on the "Fixed Tracker Artifacts" tab for any given release. This depends on setting the "Fixed in Release" fields for every artifact that merits it.
  - Communicate general availability of a release so that consumers will know that they can come and get it.
    - Use TeamForge to communicate release availability by setting file release parameters to the proper settings (e.g. "Maturity" = "General Availability") and sending an email to a discussion forum for users.