The usage model of Agilo for trac is based on the Scrum framework for software development by Ken Schwaber, Jeff Sutherland and Mike Beedle. In order to use Agilo for Scrum in the way it is intended, please make sure you understand the Scrum framework and know the featured artifacts, ceremonies and roles. You might find also some aspects which are not defined or used in the theoretical Scrum approach. These are based on practical experiences and have proven to be effective and useful. These aspects are marked with our logo.
In Agilo you can not only create different items, like Requirements, User Stories or Tasks, but you can also create links between them. These links are bidirectional. This unique functionality of Agilo for trac helps you for example to analyze the impact of a change or a bug, or to estimate new versions of a product.
If you need any support to implement Scrum, please don’t hesitate to contact us for further information: www.AgiloSoftware.com, firstname.lastname@example.org
The Product Owner (PO) prepares the Product Backlog with Requirements and User Stories by adding and editing tickets of the related type.
At this point do not set the “milestone” property yet, just list the requirements and User Stories, starting from the requirements that from a Product Owner perspective are considered the most important ones.
You may want to create a vision in the wiki and link specific parts of it to requirement tickets. Using the "Edit" tab of a requirement ticket you can add linked User Stories. We write acceptance criteria as a part of the User Story description. Some Agilo’s Users create a ticket type called “Acceptance Test” and link those tickets to the adequate User Stories and Requirements. (You can add/link external documents to every item at any time).
The PO calls the stakeholder for a Product Management Board meeting. They play the Business Value Game to assigns Business Value Points to the Requirements. The stakeholders are typically not interested in the detailed User Stories.
The PO invites the Team to the Sprint Planning Meeting. He uses the Product Backlog Report as a guideline (it is sorted by Business Value Points so far) and presents one after the next Requirements and related User Stories to the Team.
The team estimates the Requirements and User Stories using Planning Poker, and the PO assigns the estimated User Story Points to every User Story. Doing so, the Product Backlog Report resorts automatically according to the ROIF (Return On Investment Factor) - the potential return on investment, if a requirement would be completed in one iteration.
According to the priorities of the PO the team chooses now the User Stories they think they will be able to implement within the end of the Sprint. The PO assigns these User Stories to the Sprint by setting the „milestone“ field of each User Story. After the milestone is set, the User Stories will appear in the selected Product Backlog Report for the Sprint (Sprint Backlog), and will disappear from the Product Backlog Report. In case some User Stories will not be completed, than they can either be put back to the Product Backlog (unsetting the milestone property) or moved to the next Sprint.
The PO can leave now, because the Team gave an initial commitment for the Sprint. The Team starts now the detailed planning with the Scrum Master. The Scrum Master can login to Agilo for Scrum and open the Sprint Backlog view, where he will find all the committed User Stories, and where the first day of the Sprint is highlighted as today. (Please make sure that the milestone end date has been set, as well as the duration of the Sprint. To do this as a Scrum Master, enter the Sprint Backlog view and set the Sprint duration which will be calculated back from the milestone date). Now the team, with the help of the Scrum Master, starts to dig down into each User Story and creates Tasks by going to the „Edit“ pane of the story and creating a linked Task. The Team goes on laying down as many tasks as needed for the whole User Story. Afterwards the Scrum Master switches back to the Sprint Backlog, where the Team can estimate the remaining time for each task
You can also estimate instantly while creating Tasks, but we have experienced that if the team can have the whole picture, the estimations are more balanced and less reworked. It is all about speed and time box right?! ;-)
When the time box is over, the Scrum Master can calculate the ratio: User Story Points divided by hours (the sum of User Stories Points of all User Stories completely broken down into Tasks divided by the sum of the estimated time of all the Tasks related to those Stories) and use that number with the remaining User Stories which are not yet broken down into Tasks, by creating -for now- a placeholder Task with the current estimated remaining time, so that the initial burn down will be set, and the team can have a look whether it is still fitting in their capacity or not. (Here we will implement some more automation soon, just be patient for now please...)
The Sprint starts, and on a daily basis the Team assigns/accepts Tasks and reports progress. When Tasks are in progress (status „accepted“) you can see them in orange in the Sprint Backlog, and the owner of a Task can also edit the remaining time for it. Done Tasks appear green.
Because Agilo for trac as been build as a tool to support Scrum Ceremonies, we do suggest to update the remaining time of the tasks at the daily stand-up meeting together with the rest of the team. In this way the whole team will have an idea of the progress done and can pick-up very well the Inspect & Adapt process.
Every Team Member can also create Tasks for the Sprint, which are not related to any User Story. If they want to link them to a User Story, they need the Scrum Master to link it to a User Story afterwards.
If you need any help for your projects, please don't hesitate to contact us →
The agile42 Team