by Brad on 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
- 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.
- How many of you believe sprint deadlines are a positive motivation?
- 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.
by Brad on December 17, 2009
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).
Above: dragging a user story from the backlog to a sprint. (Click image to see it full-size.)
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.
Above: The Task Board in summary view mode (Click image to see it full-size.)
Above: See more of the task board without scrolling – the List view (Click image to see it full-size.)
Above: Dragging a card from “To Do” to “In Progress”
Above: Double click to see this expanded view of any card on the board.
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.
Above: Burn down in hours (Click image to see it full-size.)
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.
Above: The column turns red when the WIP limit is exceeded
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?
- 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.
- 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.
- 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.
