Agilo for Scrum: A Review

by Brad on November 2, 2011

Some time ago, I reviewed several open source Agile Application Lifecycle Management (ALM) tools (aka project management tools). One of those tools was Agilo for Trac version 1 (which has been updated since my review). Agilo Software, the company behind the tool, has released a new tool independent of the Trac platform called Agilo for Scrum, which I’ll review in this post.

In summary, Agilo for Scrum is a very intuitive, easy-to-use tool. Because it’s entirely web-based and hosted SaaS, you can get started with it in just a few minutes. The interface is designed in a way that it steps you through the process of creating a backlog, creating a sprint, populating a sprint with backlog items (stories), creating tasks for your stories, and then visually tracking progress of work through the sprint. No documentation is necessary to figure it out, although it does have a good quick start guide. While it’s simple and easy to use, it doesn’t yet offer advanced features or support large organizations with multi-project programs, although multiple teams will be supported in the next release. The bottom line is that right now it’s a great tool for single-team projects, and hopefully soon will be great for more complex projects.

Pros

  • Simple to use and easy to get started
  • Intuitive and well-designed interface
  • Great for single-team projects, especially geographically distributed teams
  • Nice visual task board view with drag-and-drop functionality

Cons

  • Each license/instance supports only a single backlog
  • Cannot attach files to backlog items or tasks
  • No API nor data import/export
  • Defects are not included as a specific type of backlog item

Screen shots

Feature Summary

The table below summarizes the major features of Agilo for Scrum.
Version 01 November 2011 No version number specified.
License Monthly subscription, 45 Euros per team. Software is proprietary to Agilo Software GmbH.
Platform Web-based SaaS
Backlog ordering Drag and drop to order backlog items
Story points Yes Pseudo-Fibonacci scale only.
Task hours Yes
Task board view Yes Planned, In Progress, Done
Iteration burn down chart Yes By hours and story points
Epics, or a hierarchy of backlog items Yes, with Themes Themes group related stories together. Go to the hierarchy view in the backlog to use this feature.
Release planning (multiple sprints) No
Roadmap view (multiple releases) No
Multiple products/ projects No Feature is planned for a future version.
Portfolio planning No
Acceptance tests Text area to capture simple acceptance criteria
Impediment tracking Yes
Defects as backlog item type No
Story Themes Yes
Teams Yes. 1 team per licensed instance. Multiple teams (with a single backlog) planned for the next release.
User roles Admin, Scrum Master, Product Owner, Team member.
Reports Sprint burndown
Integration & API(s) No
Dev status Active
Support By email.
Forums Uservoice for submitting defects or enhancement requests.
User docs Quick Start Guide
Usability Intuitive
Suitability for large programs or organizations Suitable only for a single team and project.

In the interest of full disclosure, I am a partner of Agile42, the company that develops Agilo Software. I’ve done my best to write an impartial review.

{ 0 comments }

The Secrets of Successful Test Automation

by Brad on October 25, 2011

Lisa Crispin presented The Secrets of Successful Test Automation at yesterday’s Agile Denver meeting. I’ve summarized them here with some of my interpretations.

  1. Whole team ownership of and commitment to quality and testing. Leverage everyone’s strengths.
  2. Pair programmers with testers for both unit and acceptance tests. My commentary: do this regularly even if you don’t do it full time.
  3. Use a framework that allows non-programmers to write test cases (like fitnesse)
  4. Use a programming language for tests (or your automated test framework) that the programmers know well
  5. Use continuous integration for fast feedback
  6. Run periodic “engineering sprints” when team can do whatever they want (e.g. to reduce debt or upgrade tools)
  7. Make it a team responsibility to automate all regression tests. Require everyone to run manual regression tests to motive them to automate.
  8. Stop the line to fix failing tests. My commentary: this requires commitment to quality from management and discipline by the development team.
  9. Continually refactor test code, just like production code. Test code deserves same respect as production code.
  10. Under-commit. Plan less than you think you can do so you have time for unexpected things and test automation. My commentary: I don’t like to use the term “under commit” because it’s likely to get managers and stakeholders to push back. What it really comes down to is working at a sustainable pace, with a commitment to quality and discipline.
  11. Expect some time to ”get over the hump” before the investment in test automation pays off with reduced testing effort.

There were a few items Lisa didn’t explicitly list as secrets but were implied:

  • passionate people
  • strong teamwork and collaboration

Others in the audience shared some interesting ideas of their own. Here are a few:

  • Programmers write some happy path automated tests first and then testers can expand on them.
  • Periodically set aside a day as testing day for the whole team. (Suggested by Mark Waite)
  • Use Test-driven bug fixing. Require and automated test for every bug fix. This can also be a way to get the team to “dip their toes in the water” of TDD.
  • Budget some amount of team capacity every sprint for debt reduction.

{ 13 comments }

Jira query for the current version or sprint

October 17, 2011

Jira dashboard widgets and the Rapid Board both can be built from any Jira query (JQL). It’s often useful to create a report or rapid view board that reports on the current sprint, or latest sprint. Here is the JQL that will show all issues in the current sprint (Fix Version) for a project named [...]

Read the full article →

The Importance of Culture

September 6, 2011

Gary Kelly, Chairman and CEO of Southwest Airlines, writes in the September 2011 edition of Spirit magazine about the importance of culture in his company’s phenomenal success in a turbulent industry. Comparing Southwest with it’s competitors, he writes: The biggest difference between Southwest and the rest was the attention to Culture. Not just a differentiator, [...]

Read the full article →

The Seven Deadly Sins of Agile Testing

March 22, 2011

I had the honor of presenting at the 2011 SQuAD conference on The Seven Deadly Sins of Agile Testing. It was a highly interactive session where participants gathered in small groups to identify penances, or ways they can avoid the seven sins. I provided a set of cards with ideas, and participants generated their own [...]

Read the full article →

Backlog items for refactoring tasks

February 9, 2011

In an ideal world, teams are be highly disciplined with XP practices, and refactoring is part of the Definition of Done for each backlog item; refactoring does not need to be planned separately in the backlog. In the real world, teams may inherit code with a lot of technical debt, or they may have (shame [...]

Read the full article →

Stopping the Snowball Effect with Fixed-Date Releases

October 6, 2010

Agile release planning can be either date-driven or scope-driven. The approach is mostly the same both ways. We estimate the product backlog, typically using story points for each backlog item, and then estimate or measure the team’s velocity in story points per sprint (for Scrum teams) to estimate either the date to deliver the scope, [...]

Read the full article →

Using Innovation Games® to Build a Better Product

October 6, 2010

Last month I had the great privilege to attend the Innovation Games® Master Course taught my Luke Hohmann, author of the book Innovation Games: Creating Breakthrough Products Through Collaborative Play. I was one of several Agile Coaches and Scrum Trainers in attendance, along with product managers and UI/UX designers.  If you’re thinking “I don’t have [...]

Read the full article →

Dynamic Team Estimation in Action

May 29, 2010

This week I coached a product team in Shanghai consisting of 3 Scrum teams (about 8 people per team) working on a single backlog. The challenge: how to estimate a backlog of 200 items for the team’s first release planning session, without taking all day? The solution: Dynamic Team Estimation I’ve blogged previously about Steve [...]

Read the full article →

Potential Dysfunctions of Sprint Commitments

March 11, 2010

Many Scrum teams subscribe to the following set of rules, which are the prevailing guidance in the Scrum community and literature. At the beginning of a sprint, the team commits to delivering some number of backlog items Teams should not start work on a backlog item unless it can be finished in the same sprint [...]

Read the full article →

← Previous Entries