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.

All good agile teams have a Definition of Done (DoD) – the common set of criteria that every feature must meet before it’s considered complete. I wrote about the DoD previously in this post. But what about a Definition of Ready? How do you know when your backlog items are ready for the team to accept them?

Serge Beaumont spoke on this topic among others at the 2009 Scrum Gathering in Munich in his presentation Practical Tools for the Product Owner: Focus, Value, Flow. He describes the Definition of Ready as a negotiation between the Product Owner and the team, where the team ultimately decides if a backlog item (user story) is defined well enough for the team to estimate and implement. His checklist for the DoR for backlog items includes:

• Why? Business Value
• What? Outcome vision
• How? Implementation strategy & cost
• Does the backlog have enough items for 1 and half to 2 sprints?
• Is the size (granularity) of the backlog items acceptable?

I would personally aim for a smaller number of items in the “ready” state; 2 sprints worth of items increases the risk that time will be spent analyzing items that end up in the trash heap.

Serge also advocates using a kanban board with 4 phases to track the readiness of backlog items:

• New
• Preparing (going through analysis)
• Ready
• In sprint

I’ll be adding the DoR as a standard part of my Scrum implementations.

A tip of the hat to Paul Rayner for recommending SourceMonitor for .NET code quality metrics. I gave this freeware tool a spin today on a C# project I’m working on for a large client, and was very happy. It’s easy to use and within a few minutes I had it installed and ran the analysis on the whole project, gathering these metrics for the whole solution, and for each C# file within the solution:

• number of statements
• methods per class
• calls per method
• statements per method
• average and maximum complexity
• average and maximum block depth (number of levels of indentation/curly braces)

This is a great tool to quickly find potential problem spots within the solution, so you can identify the components that would likely benefit the most from some refactoring and additional testing.

The following is a fable to compare traditional waterfall projects to agile/lean projects…

Announcing my new movie rental service, NetPix! Here’s how it works.

• You get 60 movies each year, delivered on DVD in the mail.
• When you first sign up, choose 60 movies you want. When you finish choosing your movies, we’ll confirm that it’s really the list you want.
• Over the next 12 months, NetPix will tirelessly collect your 60 DVDs, and at the end of the year, we’ll deliver all 60 movies to your home!
• Price: $60 per year (just $5 per month!)

The fine print:

• DVDs will be delivered 12 months after you complete and confirm your list of 60 movies. 
• After confirming your movie list, any changes you make to the list in the first 6 months will incur a charge of $2 per movie. 
• Any changes in your movie list during months 7-12 will result in a charge of $3 per movie, and a delivery delay of 1 month per movie changed. (We have to lock down the list at some time, after all!)

And to top it off, eight months into the year the studio released a remastered, Director’s cut, collector’s edition of my all-time favorite movie “Blazing Saddles”, with never-before-seen outtakes! If I want that it’ll cost me an extra $3 (5% more) and I’ll have to wait an extra month for all of my DVDs! Double damn!

Would you buy this? “No,” you say? Well why not? This is the way software customers have been buying software for decades! Customers have to figure out everything we want before we even start working on it, and they can’t change their minds later without paying dearly for it!

Alas, much to the chagrin of NetPix, along comes an upstart disruptor, NetFlix! Now customers can get the features (DVDs) they want every month instead of waiting a year! And they can change their priorities (movie list) at any time! And they can watch “Weekend at Bernie’s I” before deciding if they want to invest 90 irrecoverable minutes of their lives watching the sequal. The demise of NetPix is written on the wall!

At last night’s Agile Denver meeting, I facilitated an open space discussion and one of the topics was conducting more effective retrospective meetings. The group had some great insights and advice that I’d like to share here. Thanks to everyone who participated!

1. Rotate responsibility for facilitating the retrospective. Get fresh perspectives and creative ideas. Don’t let it get stale.
2. Hold your retrospective over a happy hour.
3. Read Agile Retrospectives by Esther Derby and Diana Larsen
4. Instead of asking “what were the problems”, ask “what could we have done better.”
5. Follow through with an action plan. If you have lots of improvements, rank them and work on the top priority issue.
6. Have a virtual buyer/seller transaction at the end of your iteration to determine if stakeholders are willing to “pay” for what you delivered.
7. Do shorter iterations – fewer issues to discuss
8. Set the stage with expectation that it’s not about blaming. Participants must describe the effect of the problem, not the person they believe caused the problem.
9. Take collective team ownership over problems. It’s the team’s job to help every person on the team.
10. Start the meeting by having participants write issues on cards, then post them on a wall and group them. This can effectively elicit input from shy people who are hesitant to speak in a group.
11. Ask creative questions, like “if this iteration were a car, what model would it be?”
12. Keep a retrospective board where team members can at any time write down issues they want to discuss in the retro.
13. Is there an elephant in the room that nobody wants to talk about? If so, get it out!
14. End on a positive note. Everyone must say one positive thing.

I authored a comparison of five open source agile project management tools: Agilefant, IceScrum, Agilo, eXPlainPMT, and XPlanner. The article is posted on Open Logic’s Wazi site. I welcome your feedback!

Agile methods were originally intended for small co-located teams. Can they work for geographically distributed teams? In fact, due to the challenges of working with distributed teams, I believe the fast feedback and validation afforded by agile methods provide a distinct advantage for distributed teams because problems are found sooner. I have experienced great success with teams split between the US, India and China. In this post I share some tips on making distributed agile teams succeed.

For a more in-depth treatment of this topic, see my presentation on Distributed & Offshore Agile Teams.

1. Prepare your collaboration infrastructure

You may need phone, web, & video conferencing, wiki/intranet, source control, VPN, remote desktop tools, SFTP for large file transfer, testing and integration environments, and project management software. Obtain high quality full-duplex speaker phones, headsets, and webcams.

2. Have an agile coach or agile champion at each location

In addition to providing agile training to every team member, you want ongoing guidance at each location from an experienced agile practitioner who can establish an effective team culture.

3. Be extra disciplined in your technical practices

The technical practices from XP (pair programming, TDD, refactoring, continuous integration, coding standard, simple design) are fundamental for any high-performing agile team, but when people are scattered across the globe, they become even more important. These practices ensure that quality is built in from the start, they enable knowledge sharing, and ensure rapid feedback.

4. Do cross-location travel throughout the project

Get the entire team together in one location at the beginning of the project and again at each release. Establish a rotating travel schedule so each team member visits another location for 1-2 iterations. This face time will reap big returns in establishing trust, sharing knowledge, and maintaining an effective team culture.

5. Maximize opportunities for real-time communication and collaboration

Even with a time zone difference, find at least a few hours every day when all team members are available by IM & phone for real-time communication. Share time zone burdens fairly between locations. Hold daily stand-ups and iteration planning meetings with the entire team using video and web conferencing. Many studies have shown that the majority of information shared in a conversation is non-verbal, so use video chat & conferencing often. Google, Yahoo and Skype offer free 2-way video, and Paltalk has free video for up to 10 parties. Webex and many other commerical services offer multi-party video conferencing.

6. Facilitate cross-cultural communication: speak slowly, avoid jargon and idioms

If your team members don’t all share the same primary language and culture, be sure that everyone speaks slowly and avoid using jargon, idioms or expressions – they usually don’t translate well. Announce your name each time you speak on a conference call: “This is Sally…” Start each meeting with a virtual seating chart as described by Jean Tabaka in her book Collaboration Explained. Appoint a facilitator to ensure each meeting is effective.

7. Find effective, lightweight tools for distributed collaboration

Intranets, wikis and source control systems allow easy information sharing. Virtual white boards such as scriblink, skrbl, and dabbleboard enable remote collaboration. Many web conferencing systems such as ReadyTalk have drawing tools allowing free-form annotation of a shared screen. Instant messaging supports both one-on-one and group chat. VNC, remote desktop and similar tools even allow cross-continent pair programming. For iteration planning and task tracking, share photos or video of your physical task board, or make the leap to an electronic tool. There are numerous open source agile tools plus commercial tools, most with trial or free editions, but choose a lightweight tool unless you truly need the more advanced features.

I am often surprised at how many self-described agile teams don’t hold retrospective meetings every iteration. For those team that do hold retrospectives, I often find they have a lot of room for making them more effective. An attitude of continuous improvement is fundamental to successful teams, and the retrospective is the primary mechanism for improving, so it follows that effective retrospectives are one of the key elements of a good agile team.

In this post, I offer five tips on how to conduct more effective retrospectives.

1. Review notes & actions from the previous retrospective

This is step #1 in the retrospective, which of course implies that you must first record notes from your retrospective meetings. (See tip #8) Use a projector to display notes & action items from the past meeting. Keep it short – five minutes at most. If you have remote team members, use a webinar and/or video conferencing so everyone sees the same screen. If you find your team bringing up the same problems as in previous iterations, ask why – five whys, actually (see tip #5).

2. Ask what problems, successes and opportunities you have with the team, the product, and the process

The facilitator will ask the team, “What did we learn about the team, the product, and the process? What were our problems, successes and opportunities to further optimize?” Capture these items in a grid as shown below. Use a white board if everyone is in the same room, or take notes in a wiki or other electronic document – preferably the same one you’ll use to archive your retrospective notes (See tip #8).

	Problems	Successes	Opportunities
Team
Product
Process

3. Let each team member speak without discussion

The facilitator gives each team member the opportunity to speak without any group discussion; no one else is allowed to comment on anyone’s opinion – yet. Only clarifying questions are allowed at this time. Discussion will come later when the team is discovering the root causes of problems. (See tip #5)

4. Vote on the most important items to take action on

You may not be able to immediately address every concern raised in the meeting, but you certainly need to prioritize them. Every team member is allowed to vote for 3 items that he/she believes are most important to take action on. Tally the votes and add the items to your process improvement backlog based on priority. Note that some items may not require any further action. Even successes may need action however; for example, a good pattern or practice may need to be documented in the Definition of Done or added to the coding standard.

5. Use “five whys” to discover the root cause of problems

For each of the highest-priority problems identified, the facilitator will ask “why did that happen?” Once an answer is given, ask the same question again, repeating the process five times. This should lead you to the true root cause of the problem.

6. Create an action plan for your top priority items

For each top priority item, decide what to do, and who can do it – which may be more than one person. Any actions requiring work by team members should be planned and assigned during iteration planning. (See tip #7) Actions assigned to members outside the team must be coordinated and scheduled. Of course the action plans should address the root causes of problems, not just the symptoms.

7. Explicitly allocate time for improvement actions

Maintain a backlog of improvement actions. At each iteration planning, pull the top improvement actions into the iteration. Improvement items should be prioritized along with product backlog items based on overall value to the organization, but teams should reach an agreement with the product owner on a percentage of their time to be spent on improvements.

8. Record your retrospectives & actions

Maintain two artifacts: (1) a process improvement backlog and (2) retrospective notes. The notes may be captured in real-time during the meeting using a wiki, intranet, or other electronic document. Record just enough information to support a review at the next retrospective (tip #1). Appoint someone other than the facilitator to take notes. For the process improvement backlog you may use the same tool you use for product backlogs; this backlog can be owned by the scrum master.