Agile take on defects in capacity planning

[Inna Shulman]

Dear community, 

when planning for upcoming iterations our teams wonder why defects do not appear in capacity calculations. They only see tasks, but not defects. 

My guess is that agile methodology has an optimistic forward looking take on planning and focuses totally on delivering a new value per product management requests. But the life is a bit more complex and once we ship, there are always defects to fix and other improvements to make that are not of immediate interest for PMs.

The way around this may be using so called focus factor to deliberately reduce the team available capacity in order to accommodate for this kind of work. The problem is that it makes the planning much less transparent and the overall calculations become less useful. 

What is your approach on this?

Thank you,
Inna

[Nik Antonelli]

Hi Inna,

In Rally, Defects are just a variant of Stories. Each of them can have tasks if you "task out", so you can have the tasks from stories and defects in the same task list and therefore, in the calculation of an individuals iteration capacity.

The tasks are used when organisations are more interested in hours counted/worked. This is usually not a good metric and is used in situations when cross-charging of time is part of the process. In Agile, we hope that organisations would focus on the output of the team rather than the individual. The PlanEstimate field on both stories and defects contributes to calculation of what the team can get done in a sprint. The Scrum Master can assess the availability of team members (holidays, training, sickness, etc.) and set a sprint capacity.

If you colour code your stories and defects, you can get an immediate view on how much of the teams effort is assigned to customer reported defects, code development related defects, new feature stories, architecture runway stories, etc., in the sprint planning page. You could also use the Custom chart app to show similar if you represented these things in a custom field.

Hope that helps.

------------------------------
Nik
Ask me a question, I'm All Ears!
Rally Sales Engineer
Rally Software
------------------------------

[Inna Shulman]

Thank you, Nik.

I see that for most part people may create tasks for US, but almost never for DE. Hence the confusion. I'll pass your suggestion on.

Thank you,
Inna

[Nik Antonelli]

Hi Inna,

Is there a way you can help the PMs understand the need for the teams to divide up their time to the overall good of the organisation, not purely to do the PMs work?

What you seem to be highlighting is one of the issues I came across at a large customer. Silo'ed behaviour means that individual teams don't get to see the big picture and therefore don't get to understand the "why" of how an organisations works. To help fix this, they mandated that all work that is done in the company had to be in Rally and connected up through the portfolio hierarchy - even those defects that come in from customers after the product has shipped. Only by seeing the complete picture of ALL the work that the company needs to do, in an open and transparent way, can everybody from the CTO to the developer, see what is being done and why.

I developed a couple of apps to try and help in this very situation. The first one says: "For my work in my project node, how does it all connect up through to the strategy?". The second one asks: "For this strategy, what is the COMPLETE picture of the 'concept to happy customer' work we have/had to do?" Of course, these apps only work if you connect everything together.

The popularity of frameworks to scale Agile comes about from an understanding that a whole organisation must have a cohesive and coherent way of doing things that gives visibility across the whole organisation. There are virtually all the bits in Rally that you need to do this. The ones that are missing are usually the subjective ones.

Sorry for the long email.....

------------------------------
Nik
Ask me a question, I'm All Ears!
Rally Sales Engineer
Rally Software
------------------------------

[Inna Shulman]

I've been advocating for this for a long time and we just started to move in the direction. Latest big win was when we managed to get all support / field bug fixes in to Rally, same projects where the teams manage feature work. 
We now have all customer issues that make it to development team recorded as US and fixes to these as DE, if it comes to this. 

But making sure there are no floating US with no parent Feature is the whole other story.

And subjective parts are huge - we are all human, I guess.

[Nik Antonelli]

Hi Inna,

If I can ever help you, please let me know. Even if it is an initial  "How do I do... in Rally" sort of question, ping me. Getting customers successful is my job here at Rally. :-)

------------------------------
Nik
Ask me a question, I'm All Ears!
Rally Sales Engineer
Rally Software
------------------------------

[Inna Shulman]

Sure, thank you very much Nik.