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

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.

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.

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, but the biggest. He goes on to describe the essence of culture.

Your business plan is what you are, but Culture is who you are.

How did Southwest maintain a strong, positive corporate culture over the years? Not just by paying lip service.

Colleen Barrett, Southwest’s President Emeritus, established a systemwide Culture Committee, which comprisesrepresentatives from each major work location. They meet quarterly to share ideas on how to keep our Culture vibrant and strong.

William Schneider wrote that “organizational culture parallels individual character.”  If you believe that building strong character is critical for individual success, that implies that investing in building  corporate culture is critical to an organization’s success.

Culture is an important factor to consider for an organization that adopts agile methods, and even more so for one attempting an agile transformation. For more on that topic, I recommend reading Michael Sahota’s insightful blog series on agile culture.

Note: I wasn’t able to find a permalink to the Spirit article, so it may be gone once the October 2011 edition is published.

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 ideas as well.  Below is a summary of the solutions the participants came up with for each of the seven sins.

Sin #7: Separation of Requirements and Tests

Sin #7 may not be quite deadly, but it definitely is a big drag on team effectiveness. When requirements are separated from tests, it’s difficult to know which one is the source of truth, and maintaining the dreading traceability matrix is time consuming. Here are some ways to cleanse your soul from this sin.

Analysts & testers are best friends!

If we want to reduce the distance between requirements and tests, we need to reduce (or eliminate) the distance between the people responsible for them. Analysts can learn how to write tests, and testers can learn how to think like analysts. Closer collaboration between analysts, testers and programmers is a core value of agile methods and will help in many ways beyond this one.

Create an executable specification

The ultimate way to eliminate the separation between requirements and tests is make an executable specification.  The tests are the spec. This provides a single source of truth. Requirements can be written in the form of tests. If you’re using a test management tool, use it also as your source for requirements. Even better, with tools like fitnesse and cucumber, these executable requirements can be automated.

Specify requirements by example

Don’t limit requirements to abstract descriptions of rules and conditions. Give a bunch of specific examples to illustrate the requirements. Tools like fitnesse make this possible. As Albert Einstein said, “Example isn’t another way to teach, it is the only way to teach”.

Practice ATDD and BDD

Acceptance test-driven development and behavior-drive development codify the notion of executable specifications.

Team commitment to TDD and CI

Test-driven development and continuous integration are practices that provide a solid foundation for creating and executable specification.

Sin #6: Testing is one “sprint” behind coding

Scrum defines the output of a Sprint as a “potentially shippable product increment”. If it’s potentially shippable, it must be tested. Period. Here are some ways to atone for this sin.

Make user stories smaller

See Richard Lawrence’s great post on patterns for splitting user stories.

Here are some more ideas to bring testing and coding into the same sprint:

• The Definition of Done for backlog items includes testing
• Keep QA involved throughout the project – especially at the beginning of each sprint
• Whole-team responsibility for quality
• Closer collaboration between programmers and testers
• Create an executable specification (see Sin #7 above)
• Specify requirements by example
• Include testing effort in release planning
• Team commitment to TDD and CI
• Minimize the effort to setup and deploy test environments
• Programmers deliver working code to testers early in the sprint/iteration
• Co-located teams
• Pair development
• Persevere through challenges
• As a last resort, you may consider increasing the sprint length, but this option has many disadvantages also.
• Consider a Scrumban/kanban process that is flow-based, rather than iteration-based. Even so, strive to keep backlog items small!

Sin #5: Unbalanced testing quadrants

The agile test quadrants define different types of testing necessary on most projects: unit testing, acceptance testing, exploratory testing, and “property” testing (performance, security, etc.). Our participants identified a few ways to absolve a team of this sin.

• Balance the testing quadrants in your Definition of Done – at the user story and release level
• Categorize tests to analyze quadrant coverage, determine proper weighting of each
• Include testing in release planning
• Automate acceptance tests, allowing more time for other quadrants
• Keep QA involved throughout the project
• Exploratory testing included in acceptance testing with the customer
• Outsourcing or in-sourcing specialized testing (performance, -ility) earlier in project

Sin #4: Ignoring Test Failures

Strong agile teams tend to have a lot of automated tests that run multiple times per day via continuous integration. All that effort might be for naught if you don’t do anything when one of those tests fails! Pay your penance, as suggested below.

• “Stop the line” when tests fail
• The Definition of Done for backlog items includes testing
• Stakeholders participate in testing
• Invest in robust automated tests
• Incentives for clean check-ins. A little peer pressure or friendly competition can help establish a culture where clean check-ins and passing tests are the expectation of everyone.

Sin #3: Lack of Test-Driven Development (TDD) and Continuous Integration (CI)

TDD and CI are core practices from Extreme Programing and agile teams will quickly hit a brick wall without them. Here are some ways for a team to get on the path toward righteousness.

• Achieve an explicit team commitment to do TDD and CI
• Invest in legacy test automation
• Make automated tests robust
• Practice ATDD and BDD
• Keep metrics on important quality indicators and monitor trends; use these metrics to demonstrate ROI on TDD and CI. Typical measures include rate of CI build failures, test coverage, manual effort level per test cycle, escaped defect counts, and customer satisfaction.
• Prioritize test automation efforts to maximize ROI
• Stakeholders participate in testing
• “Stop the line” when tests fail
• Include testing in release planning
• INVEST in user stories; they should meet the INVEST criteria. Make them small and testable.

Sin #2: Separate QA team

Scrum teams are cross-functional, meaning they include all the people and skills necessary to deliver a working product. The whole team is responsible for the quality of the product. Clearly, QA is part of the development team, rather than a separate team. Here are some virtues to strive for.

• Cross functional teams include QA
• Keep QA involved at all times
• Whole-team quality responsibility
• Closer collaboration between programmers and testers
• Include testing in release planning
• Include QA activities in the product backlog
• Co-located teams
• Open Communication

Sin #1: Waterscrumming

The last and perhaps worst of the seven sins is being Agile in name only. High quality, end-to-end tested features are the output of every iteration/sprint. While large programs with multiple teams may very well need a single hardening sprint, multiple testing sprints is just another form of waterfall. Many of the penances listed for the other six sins also apply here.

• Acquire deeper knowledge of the agile practices. Understand the lean and agile principles behind the process.
• Do a pilot project. Be disciplined about all the practices and resist the temptation to modify the practices until you’ve first tried them “by the book” for a significant time.
• Include testing in release planning. Testing is an integral part of the team and process, not an afterthought.
• Include QA activities in the product backlog. Quadrants 3 and 4 in particular may require focused effort that is not directly related to individual features built during sprints.
• Cross-functional teams include QA
• Co-located teams
• Whole-team responsibility for quality
• The Definition of Done for backlog items includes testing
• Close collaboration between programmers and testers throughout
• Create an executable specification
• Specify requirements by example
• Pair development. In particular, pairing testers with programmers is a great way to cross-train and enable shorter cycles.
• Prioritize test automation efforts to maximize ROI on test automation.
• Invest in robust automated tests. Tests should be modular and robust in the face of changes in the system.
• Better project management. Traditional PMs need to understand agile principles & practices and may need coaching to implement agile practices effectively.
• Incentives for clean check-ins
• Test First! Practice TDD, ATDD and/or BDD
• Ask for forgiveness rather than permission. Can you take the initiative to apply agile practices within your sphere of control and then demonstrate the results, rather than asking for permission first?

I welcome input from my fellow sinners who have found their own paths to righteousness. Please comment with your ideas for salvation!

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 on them!) not been disciplined about refactoring. If your team has enough technical debt to require a significant refactoring effort, how to do you write a good backlog item for refactoring? Does the concept of “user story” even work for refactoring efforts?

First, let’s agree on the definition of refactoring. I like Martin Fowler’s definition:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

I would go further to add that the goal of refactoring is to improve the internal design of code so it is more readable, maintainable, elegant, and simple; in short, so it is easier to change. Refactoring is not a smokescreen for fixing a bunch of bugs. It is not any effort to change functionality. While it may result in performance enhancements, that is not the primary goal: the performance of a system is form of external behavior.

Before starting a big refactoring effort, be sure to ask question #1: When is the right time to undertake a major refactoring effort to pay down technical debt?

Should you embark on a big refactoring effort at the end of a project, before a production release? This could be risky without a very comprehensive set of automated tests. How could you recover if the refactoring causes more harm than good? Would you be better off starting the next release with the refactoring effort?  Note: I credit my colleague Aidan Ridley with identifying this important first question.

Here are some guidelines for preparing backlog items for refactoring.

1. Keep refactoring tasks small (the “S” in INVEST). Identify a single small component or even a single class as the scope of a refactoring item.
2. Use metrics as indicators for refactoring targets. Measure code complexity, coupling & cohesion to identify good candidates for refactoring.
3. Prioritize refactoring backlog items based on the value-t0-cost ratio. The value of a particular refactoring item may be known subjectively to the team, or may be indicated by metrics.
4. Define an adequate unit testing standard before starting. Write all the unit tests required to meet the standard before doing the refactoring, and use them to validate component functionality after refactoring.
5. Identify the components and functionality that may be impacted by the refactoring, and create a test plan accordingly.
6. Create automated system-level tests (smoke tests, integration tests) in order to validate whole-system functionality, particularly for areas identified in the previous step.
7. Identify any open defects that may be fixed by a refactoring. Coordinate with the team on any defect-fixing efforts that might overlap with the refactoring effort.
8. Identify any dependencies between backlog items – refactoring or otherwise. Can you find ways to break those dependencies, such as changing the scope of an item, or creating interfaces between components to isolate work in different areas?
9. Do you need help convincing the Product Owner to prioritize the refactoring effort? Try to quantify the value of the refactoring. How much would the team’s velocity increase as a result of refactoring? What reduction in defects would you expect?

I must give credit to some of my colleagues for helping with some of the ideas in this post.

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, or the scope that fits within the date. Kanban teams may argue that estimates are waste – and in some cases they may be – but in some contexts a business needs to set clear expectations with customers, and estimating makes that possible.

The Snowball Effect

In traditional projects with long release cycles, projects tend to “snowball” out of control. No one can stand to have their feature deferred to the next release, because the next release is too far in the future. So feature creep happens. The release, snowball, on it’s way down the hill, begins to pick up more snow and debris as it rolls. At some point, it’s too big to manage and it’s going to roll a lot farther (in time) than you wanted it to. Date-driven release planning, with short timelines, is a great way to stop the snowball effect. I especially like frequent and periodic release schedules, such as quarterly releases. With this structure, think of each release as a bucket of limited size; the bucket will only hold so much work, and if you want to add more, you’ll have to take something out first. This forces a valuable conversation about priority. And because the next release is a few months away, instead of a year or more, it is much easier to defer features til the next release. You may even find (gasp!) that some of those features will ultimately not be important, and can be skipped altogether.

One of the 12 principles of the agile manifesto says “Simplicity – the art of maximizing the amount of work not done – is essential.” Use date-driven release planning to help avoid unnecessary work on your product or project.

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 time for games – I have serious work to get done,” think again. If you must, call them “collaborative product discovery workshops” instead of games, if that will keep those left-brained managers and executives more happy. These are highly effective techniques for engaging customers and stakeholders to discover how to make better products.

Here I describe a few of my favorites of the 12 games described in the book.

Speedboat

Would you like to learn what customers like and don’t like about your product or service? Instead of a solitary survey, bring your stakeholders together and see what happens when they share ideas with each other. Put a drawing of a speedboat on the wall or on a whiteboard, with an anchor below it and motor on the back. On sticky notes, participants write down things they don’t like about your product as “anchors”, and place them under the boat next to the anchor. Next, participants write things they do like – or new features they would like to see – and place them near the motor. As discussions brew among the participants, useful observations and great new ideas will emerge. I actually like a variation on the game using a sail boat instead. (Thanks to Andrea Tomasini for introducing the idea to me.) In sailboat, you still have an anchor, but you use a sail instead of the motor. In addition, I add the boat’s destination as a tropical island in the distance; customers can describe the goals they hope to accomplish with your product.  Between the boat and the island, beware of rocky reefs hidden in the waves; what risks or obstacles stand in the way of reaching the sunny destination? This game is versatile; I’ve also used it for agile retrospectives.

Buy a Feature

This game is simply brilliant. Having a hard time deciding how to prioritize features? Give each feature a cost (based on estimated effort to build, for example) and give your stakeholders play money. Not too much money, though! In fact no one participant will have enough cash to buy a single feature by himself. They’ll have to negotiate with each to decide which features are most important.

Product Box

When you need to decide the vision for your product, this is a fun and engaging way to realize it. Get a blank box the size of a cereal box, and ask each participant to create the box that would make them want to buy your product. The limited real estate on the box forces participants to decide what’s most important to them. You might think your group isn’t creative enough to do this, but you will be surprised how engaged people become, even if they’re not artists. Give them plenty of markers, pens, colored paper, magazine images, glitter, etc. and see what emerges.

The book describes nine more great games, which are a great addition to your toolbox. The Innovation Games® company has also developed online versions of many of the games, including Buy a Feature, allowing distributed groups to play collaboratively.

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 Bockman’s Team Estimation Game. This is a great alternative to planning poker which I’ve found easier for teams to understand, and much faster than planning poker. My colleague Björn Jensen and I presented some adaptations to the Team Estimation Game at the 2010 Shanghai Scrum Gathering that we call Dynamic Team Estimation. (Our presentation is available on the Resources page under Agile Estimating 2.0). We used Dynamic Team Estimation in this case and it worked very well.

First, we considered having the three teams divide the backlog and have each estimation their own subset of items. The teams, however, preferred considering the whole backlog together. Since it wouldn’t be effective to have 20+ people all trying to estimate at the same time, we asked each team to select 3 representatives who would do the estimating, being sure that we had a good cross-section of skill sets included.

Our team of 9 estimators plus Scrum Masters and Product Owner gathered in a room with a large table. Since the teams were in their 3rd sprint, we started by laying out the completed user stories on the table based on their size to serve as our basis – small items on one end of the table, large item at the other end. These stories already had story point values. The product owner printed the backlog items on half-sheets of paper and brought them in a stack ordered by priority. We laid out the top 10 or so backlog items on one end of the table and began by using the structured rules of the Team Estimation Game. One person at a time could estimate one item placing it on the table according to size, or could choose to change an estimate made previously. Players proceed in round-robin fashion, with each player explaining his or her rationale. Other players are allowed to ask clarifying questions, but not to debate the estimate – they will have that chance on their own turn. Rather than proceed in strict priority order, we allowed each player to choose any story from the 10-or-so top-ranked items we set out.

Before we could even get one time around the table, the team was wanting to bend the rules. They were having discussions about each item, and while one person was placing an item, others were looking at the yet-to-be-estimated items. We asked them to remember the rules, and to get around the table at least one time before we considered relaxing the rules.

After the first round, we asked the team if they wanted to relax the rules and instead use Dynamic Team Estimation. They quickly agreed and immediately swarmed the table. Pairs and small groups had discussions about out items, and 2-3 items were under consideration concurrently at most times. We asked the team to follow one rule now: whenever someone estimated an item (by placing it on the table), he/she would get the whole groups’ attention and explain the rationale for the estimate; this gave everyone a chance to provide input or disagree. This was important – without it, estimates might not be considered by the whole team.

We split the session into pomodoros (25 minutes of work followed by a 5-minute break). During each pomodoro, the teams invited a few other members to attend so that everyone could observe the process and contribute if needed. The Product Owner answered questions and clarified the user stories.

After 3 and a half pomodoros, the team finished estimating 200 items with smiling faces. Just a few days earlier, many team members said they didn’t think they’d be able to estimate most items, and no one (including myself) thought we could do it in less than 2 hours. Success!

The backlog is not posted on a large wall, arranged by sprint based on the team’s velocity and estimates. The whole team now has visibility into the scope of the project and can use this tool for look-ahead planning (as described by Mike Cohn).

Many Scrum teams subscribe to the following set of rules, which are the prevailing guidance in the Scrum community and literature.

1. At the beginning of a sprint, the team commits to delivering some number of backlog items
2. Teams should not start work on a backlog item unless it can be finished in the same sprint
3. Sprints should never be extended

The reasoning behind these rules are that the time pressure of a short, fixed sprint helps a team focus and get more done than they otherwise would, and that extending a sprint is a slippery slope toward anarchy. While I understand this logic, in practice I’ve seen two dysfunctions result from these tenets of Scrum.

First, in many organizations the word commitment invokes fear in the team: if we don’t deliver our commitment, we’ll be punished. As a result, teams are likely to under-commit and bring less work than they otherwise would into the Sprint. “But then they can bring in more work if they finish early,” goes the argument. But rules #2 and #3 tell them to do this only if they can finish the work by a fixed date, and the same fear factor makes them very reluctant to do this. I have actually seen teams with idle time at the end of the sprint as a result.

On teams without the fear of commitment, an entirely different dysfunction can result from these rules. While speaking to an audience of about 50 people at Agile Denver recently, I asked two questions.

1. How many of you believe sprint deadlines are a positive motivation?
2. How many of you have cut corners with quality to meet a sprint deadline?

To my surprise, only a handful of people timid raised their hands in response to the first question. To my further surprise, almost every hand in the room shot up emphatically in response to the second question. The evidence indicates that this combination of rules is having unintended consequences.

So what should we do? A few things I would recommend.

First, replace the phrase Sprint commitment with Sprint estimate. Be sure to have the crucial conversation with your team, Product Owner and stakeholders about what it means when the team accepts a set of user stories in sprint planning, and what it means if they are unable to complete all the items they estimated; particularly that no punishment will be doled out as a result. This is a good opportunity to stress the importance of limiting WIP and focusing on the highest priority items within the sprint, so that if anything isn’t finished it will be the lowest priority item.

Secondly, be sure to have good quality metrics as compensating measures for your velocity metrics. While velocity metrics give an incentive for the team to go faster, they also can result in pressure to cut quality. Effective quality metrics, such as code complexity and code coverage of automated tests, combined with practices like pair programming or code reviews, provide a balancing incentive to keep quality high.

Third, I believe it’s ok for a team to start a new backlog item even if they don’t think it can be finished by the end of the sprint, assuming that all the higher priority items are truly done and accepted by the product owner, and the team has established practices to ensure a sustainable pace with high quality. Some people might suggest that rather than starting a new story that can’t be finished by the end of the sprint, the team should do “extra” refactoring or work on resolving impediments. In my view, the team’s Definition of Done and working agreements should already ensure there is adequate time for these activities. If you wait until you have “extra” time, it’s likely that you’ll never have time.

Kanban eliminates the sprint deadline, which is another way to possibly reduce the motivations that lead to this dysfunction. But beware that kanban should not be used as an excuse to be undisciplined; perhaps that’s a topic for a separate post.

I previously blogged about using Jira with some open source tools for managing agile projects, and concluded that it was not a great solution – without GreenHopper. I’ve been using the latest version of Jira with the GreenHopper agile plugin extensively now, and I like it. It is lacking some features, which I’ll describe later, but here is an overview of the main functionality.

The first thing I like is the Planning Board view, which is aimed at Product Owners who spend lots of time ranking and re-ranking backlog items. The GreenHopper planning board allows you to drag and drop items to either change their rank or to move them from the backlog into a particular iteration or sprint (version, in Jira lingo).

For the development team, GreenHopper’s Task Board view is just that – it simulates the physical task board that so many co-located teams use. It’s easy to drag the virtual cards to columns to update their status, just like you would do with a physical board. Very nice. It also does something you can’t quite do with sticky notes; double click to see more information, or click on the item ID to see all the detail.

An advantage of GreenHopper over sticky notes on the wall is that your burn down charts are calculated automatically: in hours, number of items, and story points. The screen images below show these. The red line is the ideal burn down and the green line is the actual.

Are you a bleeding-edge adopter of kanban? GreenHopper is decent for that. The columns on your kanban board are customizable, so you can create any columns you want. You can also set a WIP limit for each column. You can’t, however, set up horizontal “swim lanes” for different service level agreements (SLAs), such as a row for items that need to be expedited.

The Jira dashboard also offers a reasonable approximation of the cumulative flow diagram (CFD) that replaces burn downs in a lean / kanban process. It does show items created vs. resolved, but it doesn’t graph items in-progress. The chart also counts sub-tasks as items, which you may not want.

Above: Almost a cumulative flow diagram. Close, but no cigar.

GreenHopper is an add-in to Jira, so you still get all of the Jira functionality unchanged. Like Jira itself, GreenHopper is extensively configurable; almost annoyingly so because there are so many options it’s hard to know what to do with them. Fortunately the default configuration is reasonable, although there are some setup steps required to enable item ranking, which is so fundamental that it should have been done out-of-the-box.

What is it lacking?

1. If you’re a large organization with a portfolio of inter-related projects, Jira + GH doesn’t do much to show you the big picture across multiple projects.
2. Although you have a hierarchy of versions, such as a release containing multiple sprints (described here), it doesn’t do much; the planning board simply indicates that one version is a “master” of the other. GreenHopper doesn’t offer a timeline view showing the version hierarchy.
3. You can create a hierarchy of backlog items, for example to have large-scale epics that contain many user stories, as described here. However, this feature isn’t enabled by default and requires an adminstrator to configure it. As an alternative, or in addition to the “epic” feature, you can create associations between items for this purpose, but there is no easy way to visualize the relationships. There is free task hierarchy plug-in that will show the hierarchy, but only for one top-level item at a time. 

Overall, especially for smaller teams without portfolio management needs, I give the tool high marks.