Capacity Planning

[Sam Dsoca]

Hi All,

While planning, should the development capacity and testing capacity be separate?

We use a tool for testing that developers don't have license as its expensive.

But even before this the team were capacity planning development and testing separately.

Now when we spoke about being generalist, the team pushed back asking can the testers develop.

In the long run they may develop, but in the short run they can't.

But when I was doing the burn down, I thought how can I create a burn down if development and testing are seen as separate activities.

Its not practical for testers to pick up development overnight.

And we put it as a team member capacity then we may be under committing at the start of the sprint.

Any help in this situation is useful.

Note: I am aware that we should try and move towards becoming more generalists. But practically its not possible in this company with the kind of people and their skills and its not easy to up skill them.

Thanks

Sam

[Ron Jeffries]

Sam,

This story says to me that the question of whether to do capacity planning separately or together is likely far from the most important concern to have.

The question of developers testing is not one of generality, it is one of how long you want to wait to get feedback on their work. If a developer can find out NOW whether their changes worked, they can move swiftly. If they have to wait until th testers get around to it, then you’ll ask them to work on something else, and by the time the word gets back to them on the first thing, they’ll have lost momentum entirely.

The fact that your developers “pushed back” is telling. I’d like to know more about it. Were they asked to do what they consider scut work under the flag of becoming generalists? Are they already overloaded, so that they interpreted what was said as a request to do more work in the same amount of time? My alarm bells are telling me that something very wrong may be going on.

You are of course right that you can’t create a useful burndown in the present situation. This is because there is no timely way for the developers (or you) to know whether they are done. 

There’s something wrong, and it doesn’t seem to me to be capacity planning.

Regards,

Ron Jeffries

www.XProgramming.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[Sam Dsoca]

So Ron,

Just to learn a bit more,

if in a team we have manual testers and technical developers, what is the ideal(or best way that any of us can think of) way to work so that there is only burndown, only one capacity plan that takes team members and availability hours into consideration rather than skill sets.

I am just trying to understand more on this issue

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Sam Dsoca]

Also no the developers are not asked to do more work, but we were thinking in terms of team members doing whatever necessary to get the stories done.

In some scenarios this means instead of pulling new stories, the developers helps with testing.

[Ron Jeffries]

Sam,

On Jan 6, 2015, at 12:16 PM, Sam Dsoca <samd...@gmail.com> wrote:

if in a team we have manual testers and technical developers, what is the ideal(or best way that any of us can think of) way to work so that there is only burndown, only one capacity plan that takes team members and availability hours into consideration rather than skill sets.

Please tell us what a “capacity plan” is and how it relates to Scrum’s notion of selecting however many backlog items you can get done in a Sprint, and getting them done.

Ron Jeffries

www.XProgramming.com

I don't necessarily agree with everything I say. -- Marshall McLuhan

[Ron Jeffries]

Why did they “push back” then?

R

On Jan 6, 2015, at 12:18 PM, Sam Dsoca <samd...@gmail.com> wrote:

Also no the developers are not asked to do more work, but we were thinking in terms of team members doing whatever necessary to get the stories done.

In some scenarios this means instead of pulling new stories, the developers helps with testing.

Ron Jeffries

ronjeffries.com

Impossible is not a fact. It is an opinion.  -- Muhammad Ali

[Sam Dsoca]

ok, 

Capacity plan in this team is calculating total number of available dev hours(We used 5 out of 8 for calculation per day) multiplied by the number of days per sprint.

This is termed as available dev capacity

Similarly for testing, we calculated testing

The dev's pushed back because they didnt want to test and though it is corrected now, our dev's were having the notion that developers shouldnt do testing.

But I hit a roadblock here as I wanted to have a team capacity and wanted to chcek how I can calculate the total available hours for the team to deliver "done" stories.

[Ron Jeffries]

Sam,

On Jan 6, 2015, at 12:24 PM, Sam Dsoca <samd...@gmail.com> wrote:

Capacity plan in this team is calculating total number of available dev hours(We used 5 out of 8 for calculation per day) multiplied by the number of days per sprint.

This is termed as available dev capacity

Similarly for testing, we calculated testing

The dev's pushed back because they didnt want to test and though it is corrected now, our dev's were having the notion that developers shouldnt do testing.

But I hit a roadblock here as I wanted to have a team capacity and wanted to chcek how I can calculate the total available hours for the team to deliver "done" stories.

The team is supposed to decide how many stories to take on. Are they doing that, or are you? 

Ron Jeffries
www.XProgramming.com
Master your instrument, master the music, then forget all that shit and just play. -- Charlie Parker

[Sam Dsoca]

It is the team deciding, but 100% off target every time, mainly because of the divide initially between development and testing.

Now I am trying to get to the notion that we should commit to deliver the story and thats we need to estimate the total effort in the coding and testing.

But still the notion from developers is that testing capacity plan should be different since testers cant code.

[Ron Jeffries]

Sam,

On Jan 6, 2015, at 12:31 PM, Sam Dsoca <samd...@gmail.com> wrote:

It is the team deciding, but 100% off target every time, mainly because of the divide initially between development and testing.

Do you mean 100% in the sense that they say they’ll do something and do nothing? Or that they promise to do N things and do about N/2? Or … what?

I’m having trouble understanding how the team could actually be deciding, yet be off every time. Something must be going on to make that happen. What do you suppose it is?

Now I am trying to get to the notion that we should commit to deliver the story and thats we need to estimate the total effort in the coding and testing.

Will estimating the story get it done faster or better? I would not think so. I would think that working as a team on the story might get it done ...

But still the notion from developers is that testing capacity plan should be different since testers cant code.

There is no “capacity plan” in Scrum. There is a forecast, and done software at the end of the Sprint. The development team is responsible for delivering done software at the end of the Sprint. Done does not mean “ready for test”. It means something a lot closer to “ready for production”, that is, “bug free” and “well designed” and “well crafted”.

Ron Jeffries

www.XProgramming.com

Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 

Of course you might plummet to the earth and die, but probably not: you were made for this.

[Sam Dsoca]

Do you mean 100% in the sense that they say they’ll do something and do nothing? Or that they promise to do N things and do about N/2? Or … what?

I’m having trouble understanding how the team could actually be deciding, yet be off every time. Something must be going on to make that happen. What do you suppose it is?

When I said 100%, it means that we commit to deliver some 5-7 stories in a spint which is equivalent to anywhere between 10-40 story points. But we deliver about 2 stories or some 7-8 story points.

I have joined the team just couple of weeks back. The company works for clients so there is lot of focus on commitment and delivery.

I believer to start with, we should focus more on the delivering quality and completing as much as possible and try to get a sustainable velocity rather than focusing on estimating, forecasting etc. 

But unfortunately, I am failing in helping the team achieve this. I am trying to identify impediments and eliminate them one by one.

But with the focus that we have on forecasting its becoming slightly tough. I am trying to improve forcasting by understanding the capacity and the issues impeding the delivery of the story.

We cant count on yesterday's weather because the project which was being run for almost 4 months before I joined never had a stable velocity(None of any 2 sprints ever had similar, same or even approximately same velocity. I am not talking about consequent sprints, at the moment thats a distant dream. But I am talking of any 2 sprints having a same velocity). Our sprints are 2 weeeks in length.

Will estimating the story get it done faster or better? I would not think so. I would think that working as a team on the story might get it done ...

I agree, but since we work for a client we have to inform them when we will be able to complete. But since we dont have a stable velocity its hard to predict. And I

[Sam Dsoca]

Will estimating the story get it done faster or better? I would not think so. I would think that working as a team on the story might get it done ...

I agree, but since we work for a client we have to inform them when we will be able to complete. But since we dont have a stable velocity its hard to predict. And I was just trying to makse sure that we start working as team and work on delivering the complete story rather than just completing development and getting blocked at testing which was happening before.

SO I guess here the estimates were wrong. May be thats teh issue here. Because the estimates were done at the time where we completed teh development on a story but was blocked in teh testing pipeline. So may be when the stories were originally estimated the team members only gave estimations in terms of activity(development/testing).

Ron, do you think I am looking at the correct problem to solve?

[Ron Jeffries]

Hi Sam,

On Jan 7, 2015, at 3:55 AM, Sam Dsoca <samd...@gmail.com> wrote:

Do you mean 100% in the sense that they say they’ll do something and do nothing? Or that they promise to do N things and do about N/2? Or … what?

I’m having trouble understanding how the team could actually be deciding, yet be off every time. Something must be going on to make that happen. What do you suppose it is?

When I said 100%, it means that we commit to deliver some 5-7 stories in a spint which is equivalent to anywhere between 10-40 story points. But we deliver about 2 stories or some 7-8 story points.

I have joined the team just couple of weeks back. The company works for clients so there is lot of focus on commitment and delivery.

what’s your guess at why they predict 5-7 and only accomplish 2? one would think they’d stop predicting more? why would they continue to predict ten to forty(!) points when evidence is they do 7 or 8?

if i had to put money on an answer with no data, i’d bet that someone is pushing them to take on more. That is, of course, entirely counter to what Scrum says to do. 

I believer to start with, we should focus more on the delivering quality and completing as much as possible and try to get a sustainable velocity rather than focusing on estimating, forecasting etc. 

Yes. I would be tempted to help them by shortening the sprints to a week (or less) and getting one story really done, then retrospecting on what happened. In our CSD course, Chet and I use 90 minute Sprints and people get stories done.

But unfortunately, I am failing in helping the team achieve this. I am trying to identify impediments and eliminate them one by one.

But with the focus that we have on forecasting its becoming slightly tough. I am trying to improve forcasting by understanding the capacity and the issues impeding the delivery of the story.

This focus on forecasting (and, I’d guess, forecasting more than you can do) is the impediment. Since a dead ScrumMaster/Coach/WhateverYourRoleIs cannot be effective, you’ll need to work carefully around this fact. 

We cant count on yesterday's weather because the project which was being run for almost 4 months before I joined never had a stable velocity(None of any 2 sprints ever had similar, same or even approximately same velocity. I am not talking about consequent sprints, at the moment thats a distant dream. But I am talking of any 2 sprints having a same velocity). Our sprints are 2 weeeks in length.

You said above that you get about two stories and seven or eight story points. How unstable is that? 

Are you slicing the stories thinly enough? A good starting rule of thumb is to slice them down to just one acceptance test in each story. (And the acceptance test had better not contain three paragraphs, many sentences and a lot of “ands” and “ors”.)

I would definitely suggest shorter Sprints. Since I don’t care if I get fired, I’d scale back to one or two stories and get them really done. It might be possible, though, to ferret out what works by retrospecting on the few stories that do get done.

I would suggest pairing, certainly, and swarming on one story until there is no room in it for more people. I might even try mob programming, depending on the size of the group.

Will estimating the story get it done faster or better? I would not think so. I would think that working as a team on the story might get it done ...

I agree, but since we work for a client we have to inform them when we will be able to complete. But since we dont have a stable velocity its hard to predict. And I

In my view, Scrum, and Agile in general, are not about predicting when you’re going to be done. Most of us have never successfully made such a prediction. Most of us have almost always shipped late, and/or with less than hoped for in the package.

Scrum/Agile offer the opportunity to deal effectively with the fact that we always want more than we can get, by doing the most valuable things first. All that requires in order to work is a competent team who can produce things at a roughly constant rate. It sounds as if your team may actually be close to that with their story rate. To the extent that they are not, one can already see things to work on, such as not testing at the end and so on.

It sounds like your business proposition is getting in the way, but also i’m wondering why the team is behaving as it is. I’d have to observe them to know much more. But of course you can observe them, and they know why they are as they are.

I’m pretty sure cost allocation is not the answer nor on the road to an answer.

Ron Jeffries

ronjeffries.com

Perfectionism is the voice of the oppressor -- Anne Lamott

[Sam Dsoca]

Thanks Ron,

I will try and work on shorter sprints. 

I had few conversations this morning and had some more insights when I talk to some members outside of the team.

The team were directed to ignore TDD etc as the company wanted to hit a time line in delivery. Unit tests were written only when the developer had the mood. The management decided that the team need to delivery 60 points a sprint to hit target. So the code had lots of issues and bugs that the testers were finding before the story is done.

Not confirmed yet, but the team might have inflated estimates as team was scared on the 60 points issue.

All this happened before me. Now there is no talk of 60 points but still I feel team is inflating as there may be unknowns in the story in terms of technical issues and also I feel developers expecting bugs in their development and including that as part of their assessment of the size and complexity, because of the lack of confidence on the code they themselves have written earlier.

Example - if the developers worked on a complex web project , the next web project might be complex but easier as they know the complexity or the type of issues they may encounter

But if the developers haven't worked on web project, even a simple web project they may not exactly sure what to do . In this instance do you have any suggestion how I can help the team ?

I worked on helping with pairing and swarming but some how I feel this 60 story points is still imaginarily hanging on our heads as the team also tried to deliver more work now than focussing on delivering good quality work to the state of done.

I will also try to work with the management to see if they can at least for couple of sprint forget forecasting and just let the developers deliver done stories. But I am doubtful if this will be a easy conversation.

Thanks

[Ron Jeffries]

Hi Sam,

On Jan 7, 2015, at 3:59 AM, Sam Dsoca <samd...@gmail.com> wrote:

Will estimating the story get it done faster or better? I would not think so. I would think that working as a team on the story might get it done ...

I agree, but since we work for a client we have to inform them when we will be able to complete. But since we dont have a stable velocity its hard to predict. And I was just trying to makse sure that we start working as team and work on delivering the complete story rather than just completing development and getting blocked at testing which was happening before.

Scrum is about steering to success, not about predicting success. Scrum requires that the Product Owner be responsible for maximizing the ROI of the product given the budget money and time. When doing a product for a client, it’s really the client who should be deciding what to do next.

We know that there is more to do than time and money will allow, because there always is. We also know that some of the ideas for the product are good and important, and some really are not.

(See the little article I just posted, Pick Something Stupid, for one way around that.)

One way or another, someone has to make the best possible product by some unknown date. The only way to do that is to have the best possible product by EVERY date, which we do by picking the next most valuable stories, and getting them DONE, every Sprint.

SO I guess here the estimates were wrong. May be thats teh issue here. Because the estimates were done at the time where we completed teh development on a story but was blocked in teh testing pipeline. So may be when the stories were originally estimated the team members only gave estimations in terms of activity(development/testing).

Ron, do you think I am looking at the correct problem to solve?

With respect, I do not. I think the issue isn’t estimation, I think it is delivering.

First, someone needs to decide what to deliver, and they should deliver a real product increment every Sprint, and that product increment should have the next most important things in it, every Sprint.

Second, the team needs to learn how to work as a team and get things done, and not worry about who’s coding and who’s testing. Good teams don’t worry about who’s on offense and who’s on defense, who’s blocking and who’s running. They worry about moving the ball.

You and your team can do this. You just have to decide to do it and then deal with what’s in your way. And there, too, do the most important ones first.

Ron Jeffries

ronjeffries.com

[Ron Jeffries]

Hi Sam,

On Jan 7, 2015, at 9:56 AM, Sam Dsoca <samd...@gmail.com> wrote:

I will try and work on shorter sprints. 

It will help ...

I had few conversations this morning and had some more insights when I talk to some members outside of the team.

The team were directed to ignore TDD etc as the company wanted to hit a time line in delivery. Unit tests were written only when the developer had the mood. The management decided that the team need to delivery 60 points a sprint to hit target. So the code had lots of issues and bugs that the testers were finding before the story is done.

Dumb idea. Unless the product doesn’t have to work, TDD makes you go faster, not slower. Of course if it doesn’t have to work, you’re done now. :)

Not confirmed yet, but the team might have inflated estimates as team was scared on the 60 points issue.

They will have. Perhaps consciously, perhaps not. But pressure invariably causes estimates to inflate.

All this happened before me. Now there is no talk of 60 points but still I feel team is inflating as there may be unknowns in the story in terms of technical issues and also I feel developers expecting bugs in their development and including that as part of their assessment of the size and complexity, because of the lack of confidence on the code they themselves have written earlier.

Yes. They need to produce code in which they can be confident. This will require collaboration between developers and testers, not just passing the code on knowing full well it will come back.

Example - if the developers worked on a complex web project , the next web project might be complex but easier as they know the complexity or the type of issues they may encounter

Sure. But next week we know more than this week. So we can improve now, we don’t have to wait until next project.

But if the developers haven't worked on web project, even a simple web project they may not exactly sure what to do . In this instance do you have any suggestion how I can help the team ?

Small stories. Google. Local people who know. Working together. ...

I worked on helping with pairing and swarming but some how I feel this 60 story points is still imaginarily hanging on our heads as the team also tried to deliver more work now than focussing on delivering good quality work to the state of done.

Probably. But I suppose it does have to work. So maybe delivering more crap isn’t better. Management pressure can make it seem better, but it never is.

I will also try to work with the management to see if they can at least for couple of sprint forget forecasting and just let the developers deliver done stories. But I am doubtful if this will be a easy conversation.

No, it won’t. There are probably games and exercises one could do, demonstrations one could give, that would help them understand. 

But you have to not lose your job by trying to help too hard. Maybe bring someone in to tell the bad part of the story.

Good luck ...

Ron Jeffries

ronjeffries.com

If it is more than you need, it is waste. -- Andy Seidl