Agilo Support

Page to capture answers given on the support group.

Test Case Tracking

Q: We would like to do test-case tracking with Agilo, such that acceptance tests are linked to the user stories and tasks they support. Is there a way to do this?

A: "There is always more than one way to do it..." L.W.

It will actually depend on what you really need to trace separately. I just put here two options for you to test... there are many more :-)

1) Create a Field called Acceptance Criteria as Textarea, and make it a field of the Story, than you can plan tasks for testing definition and execution. The whole story will be finished when coded/documented/tested/integrated, this is the Scrum Way :-)

2) Create a ticket type called Acceptance, define a Link Story->Acceptance, Acceptance->Task and you will have Acceptance split from stories, but linked, containing their own tasks. You won't have any specialized visualization in the backlog though, they will all appear with the style of tasks

Requirement Example

Q: Can you give an example of a good Requirement?

A: Basic difference/guidelines for Requirements vs. Story/Epic/Theme:

1) Requirements are Problem Statement or Need statement => WHAT? and WHY? And they need to be SMART (Simple, Measurable, Achievable, Realistic and Traceable). To make you a sensible example, let's think about the Amazon website and a user who wants to buy a book on the site. Example of Requirements Could be:

R1: Users need to buy books using our portals, and possibly become


R2: Customers need to find reasons to buy ore books

2) Stories, Epics and Themes (which are variants of Stories) are more or less a functional description on HOW a specific user role will fulfil a defined need using the Amazon Portal. Examples:

R1:S1: As a user I want to be able to search for a book, so that I

can decide to buy it

This is a very high level story, there are many way to search for a book, so looks like we discovered a Theme, than can be expanded as follows:

R1:T1:S1: As a user I want to be able to search for a book by ISBN

number, so that I can find it really fast without having to look into multiple results

R1:T1:S2: As a user I want to be able to search for a book by title,

and limit the search to it, so that I can exclude all the books with no specific title matching

R1:T1:S3: As a user I want to be able to search for a book by

author, so that I can see other book that the author has written and eventually find out newer edition of the one I am looking for

Beside the fact that some of them can look funny, the idea is that all three belongs to the same Theme, which is "a rubber band, packing some stories with affinity together" (Mike Cohn). Each of these is a step toward the "Solution" to the problem R1.

R1:S2: As a user, once I found a book I want to be able to buy it

and pay with my credit card

In this case the story entails a more complex process "business process" and require further analysis and breakdown, to be more precise, in this case it is an Epic, you can think of breaking it down in:

R1:E1:S1: As a user I want to be able to select a book and start the

checkout process

R1:E1:S2: As a user I want to be able to pay using a credit card R1:E1:S3: As a user I want to have a confirmation of the order R1:E1:S4: As a user I want to have a receipt for my book

While also in this case the stories belong together, the difference is that they may only occur in the given order... so they are bound by a time-sequence that can't be altered. So the Epic describe the overall process and the stories are the steps in it. Also in this case the point is that the Epic is still not a requirement, but one of the possible multiple ways of solving part of the R1 problem.

In Agile42 we make large use of Requirements, especially in complex projects, because it is much easier to find common solutions (and reusable) when you have a clear "Problem" statement, rather than when you have to compare with all the already existing solutions. In particular the usage of Requirements allows for a complete separation of Business concerns (Business Value, Budget, Solution Selling approach) from planning, development concerns, allowing to have Product Owners in full control of the Release Planning, and eventually some Solution Owner taking care of high level business planning.

Agilo Overview

The idea behind Agilo is that some ticket types are related to a Sprint, and some to a Milestone (which represent a product release). We use to plan Requirement for Milestones, representing the "wish" of the Product Owner to have those requirements implemented for that product release. If you have a release backlog in place, you will see all the stories, connected to the requirements appear in that backlog (if you have the option "strict" off) so you do not need to plan stories for Milestones.

At a sprint level, when a team (you can have many working on the same product backlog) decide to commit to a story, you can (from the release backlog, enabling the "sprint" as editable field - you need to be a product owner as well) plan a story for a specific sprint, and it will flow in the sprint backlog of that sprint (which belongs to a team). The story will still show up in your release backlog, which will be also tracking the status of completion, when stories are done, they will appear as such on the backlog. You can also use the standard trac statistics (going to the /roadmap view) and check how many stories/tasks/requirements have been already solved.

If you try to plan Milestone explicitly for stories or tasks (which according to scrum you should not do, cause the team needs to choose what they can do in one iteration) you may end up with strange behaviour, cause we implemented some "Business Rules" to synchronise Milestones and Sprints... you can disable this (go to admin/plugins, open agilo, and you should find the rule that you can deactivate...) but we can't support if the behaviour is not as expected - we need to have some boundaries :-)

If you plan to use Agilo in production, I suggest you to take a look at our "support" contracts:

Last modified 10 years ago Last modified on 02/25/2009 05:30:02 PM

1.3.15 © 2008-2016 Agilo Software all rights reserved (this page was served in: 0.17646 sec.)