Iteration planning tool

Question

Hi,

I have several problems planning an iteration for a single week. We use XP and TDD in Pairs and it is hard to decide who is pairing with whom. Is there any tool support for planning an iteration that also supports panning of pairs.

Answer 1

I suggest using a product such as VersionOne.com. With this product you can either load up your projects (resources, etc.) into their online version or you can grab a copy of their product and install it to your local servers. This is not a free product but for the non-enterprise version you do have the first year to try it for free! It is similar to crack...give the first taste cheap to get you hooked. Great product though. I have yet to meet an agile team that didn't enjoy working in this environment.

If this is not your cup of tea though there is a product out from the folks at ThoughtWorks.com called Mingle which I have been eye-balling for a while now. This looks to be a wonderful product as well. I have not yet used it though...but have spent a fair amount of time researching it and chatting with others about it. Very slick product!

Answer 2

There are quite a few products available for agile/scrum teams... have a look at http://userstories.com/products for a decent list.

We use versionOne where I work, and it does some things quite well, and other things... not so much.

You'll need to use a product for a little while, at a low level and a high level to make sure it fits your needs.

As part of a scrum team, I deal most with planning and writing sprints/stories, and tracking progress of my work. Thus for me, those are the two most important pieces to get right.

That said, I don't know if this is addressing the "planning in pairs" question -- what exactly are you trying to achieve? Is there a reason you are trying to avoid your devs make that decision? Are you trying to rotate teams all the time? Does everyone always want to pair with one person? You could always just pair up people based on who wants to work a particular story...

Without a better understanding of you constraints, I wouldn't know how to answer that part of the question. I also doubt that how to pair up is something you should be using a tool for.

Make pairs based upon working style, or people who work well together and can communicate easily with each other, or have different strengths.

Avoid vastly different experience levels, since that doesn't always encourage discussions, and is more apprpriate for mentoring than pairing.

Answer 3

In XP you don't plan who pairs with who and when. Team members just pick a task to work on at the start of the day, in the daily stand-up meeting. If someone else also wants to work on the task, they'll volunteer to pair on it. Team members who do not pick a task first will pair with someone who did. Sometimes the person who picked a task will want to use the expertise of another team-member and so will ask them to pair with them. But that person may have something more critical to work on and decide not to. Pairs often switch while a task is in progress, especially if it takes more than a day to complete.

So, pairing up on tasks is fluid and informal.

The one thing to keep an eye on is that everyone on the team pairs regularly with everyone else. If that is not happening, it can indicate a deeper problem in the team -- someone not pulling their weight or people who do not get on, for example. If left to fester this can lead to siloed knowledge and key-man dependencies that increase project risk.

In those situations, some teams like to use "pair stairs" to keep track of pairing and highlight problems.

However, that is just addressing the symptoms (uneven pairing) not the underlying problem. It's better to address the problem head-on in a safe environment (e.g. run a retrospective) and work out how to solve it.

Answer 4

Glad to see you are pairing and using TDD. WIth pairing, rotating pairs is important. However, for any story card, it is important that a developer stay with the card from start to finish. That person is the primary half of the pair.

So you have two issues. How should you handle rotating pairs, and how to you track the burn down in XPlanner or some other iteration tracking tool.

Regarding the burndown, the primary developer can be assigned to the card and responsible for updating the burndown daily. For pairing, you should have a big visible chart (BVC) showing the pairing schedule. This will ensure that all developers pair with each of the team members and help ensure that the code is shared across the team.