Is this the way number of sprints for a project is planned in Agile?

[Satyaprakash Joshii]

I want to get idea on how the number of Sprints are planned for any project.Is below the way the number of Sprints are planned?

Suppose, for an average member of the team the entire development work is estimated to take 400 hours.

Assuming resource will be productive for 6 hours a day only (not 8), this will be done in 400/6 = 66.67 days.

If the number of resources will be 5 this will done in 66.67/5= 13.34 days.


Each sprint will be of 10 days so this will be covered in 2 sprints.


before this sprint there will be a sprint 0 too.
After this, there will be a sprint required for deployment to production , so keeping a sprint for this.


So in all this work is estimated to be done in 4 Sprints.

Sprint 0 , Sprint 1, Sprint 2 , Sprint 3 (deployment to production).

However, some of the resources may take planned or unplanned leaves so that is not accounted yet.

Is this the way projects work is estimated in Agile?

[Stephan van Hulst]

There is no definite way. Agile is an abstract concept, not a set of specific rules.

What you have now sounds agile to me, as long as you realize that you now only have a gross estimate of when the product could be deployed, an estimate that you should not get too attached to, as work is evaluated on a sprint-by-sprint basis. You can factor planned leave into your gross estimate, but unplanned delays may push back your schedule. Make sure you readjust your estimate at the end of every sprint, and inform people who depend on the estimate.

[Dave Tolls]

Also note, if you're doing 2 week sprints then you really only have 9 days, not 10.  Most sprint related stuff takes up pretty much a day a sprint.
I know that might fall under the "6 hours in 8", but I would say that covers the inevitable dependency gridlock that will appear.

As Stephan says, though, it really is a "finger-in-the-air" value, subject to change over the sprints.

[Jeanne Boyarsky]

Two things jump out at me:

1) A sprint for deploying to production. - the product should be production ready at the end of each sprint whether it goes to production or not. This means actually moving to production shouldn't be a big ceremony.
2) How do you know it will take 400 hours? For release planning, a feel for how many sprints the customer wants to spend is fine. However, the work should be prioritized and re-planned each sprint, not just divided by 4.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:Two things jump out at me:

1) A sprint for deploying to production. - the product should be production ready at the end of each sprint whether it goes to production or not. This means actually moving to production shouldn't be a big ceremony.

Agreed. It should be a 1 day work may be.

.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:
2) How do you know it will take 400 hours? .

Team will have both experienced  developers and freshers. Suppose some quickest developers  can do that in 300 hours and some slowest can do that in 500 hours. I tried to take average as  400 hours.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:  However, the work should be prioritized and re-planned each sprint, not just divided by 4.

by dividing by 4 are you referring to the work to be done in  4 sprints?

[Satyaprakash Joshii]

Satyaprakash Joshii wrote:


If the number of resources will be 5 this will done in 66.67/5= 13.34 days.

In practical it will not be divided by 5 for 5 developers because lot of time will go in team coordination and discussions too. So what should be the approach. Should it be divided by 5 plus something or what.

[Jeanne Boyarsky]

It's the dividing. I like how Stephan explained it. The dividing gets a feel for things. It's not a commitment. The work can change every sprint.

Stephan van Hulst wrote:as long as you realize that you now only have a gross estimate of when the product could be deployed, an estimate that you should not get too attached to, as work is evaluated on a sprint-by-sprint basis. You can factor planned leave into your gross estimate, but unplanned delays may push back your schedule. Make sure you readjust your estimate at the end of every sprint, and inform people who depend on the estimate.

[Satyaprakash Joshii]

While management does these things, I thought it would be good to get an idea of how planning happens. Thank You.

[Satyaprakash Joshii]

Satyaprakash Joshii wrote:

If the number of resources will be 5 this will done in 66.67/5= 13.34 days.

I have a doubt here. Let me take an example. If it is estimated that team with 3 developers can do the development work in say 5 sprints ,then increasing the developers to 6 may bring it down to may be 4 sprints. But where is limit. How do they decide on the number developers. I know in this way increasing to 20 developers will not make the work to be done in 1 sprint. So how do they decide on the number of developers that will work on it?

[Junilu Lacar]

The rule of thumb is 7 plus or minus 2 for an ideal team size. More than that, communication and coordination overhead starts to slow things down. The work then gets broken down according to the capacity of the team.

This is not the only consideration either. There are budget considerations, there may be work that needs specialist skills, etc.

[Satyaprakash Joshii]

Junilu Lacar wrote:The rule of thumb is 7 plus or minus 2 for an ideal team size.

Does this count include only the developers or the sum of  developers, testers (QA), project manager and not the only ones who code.?

[Dave Tolls]

Don't know about Junilu, but up to 9 developers would be a huge team.  Be like herding cats.

[Junilu Lacar]

There's 7±2 and also the two-pizza team size (whole team can be fed with two pizzas, not the huge 48"+ pizzas either, just your average size takeout pizza)

9 people is on the plus side. The teams I've had have been about 5-7 people, which includes members who focus on tests, db, etc. You want a T-shaped team as well as T-shaped individuals, with both depth and breadth of knowledge and skills.

On my coaching engagements, it's very typical for me to find teams of 15-20 people. We usually work on breaking down the work and right-sizing towards the 7±2 or two-pizza team size.

[Junilu Lacar]

Regarding the original question, let's be honest: unless the work is more or less something you've done many times before and have a good sense of what it takes to complete or the variability is very low, it's disingenuous to say "We have this batch of work and we think it will take 400 hours to complete it." Statistically, you've probably underestimated that work by as much as 100%, maybe even more. It's the cone of uncertainty.

If you want to be truly honest and transparent, you might take a sampling of the work to tackle at first, get it done, then extrapolate from your experience what it might take you to complete the rest of the work. As you work on each small batch of work, you'll get a better sense of what's involved and will be better able to forecast what it will take to complete the remaining work. If there's a high degree of variability, then your best bet will be to break down the work into smaller chunks. Working with smaller batch sizes and working in timeboxes are two main strategies when working in an agile manner for managing complexity and being able to give better estimates.

[Satyaprakash Joshii]

Junilu Lacar wrote:The teams I've had have been about 5-7 people, which includes members who focus on tests, db, etc.

While all members will contribute to the time to be taken, I think the time to be taken depends most on the developers who are doing the coding (more than the one doing QA, dB etc).

[Junilu Lacar]

Depends on what kind of assumptions you're making. When a team is mobbing, it takes the whole team to complete a backlog item. It sounds to me like your "team" really works individually.

[Satyaprakash Joshii]

Junilu Lacar wrote:Regarding the original question, let's be honest: unless the work is more or less something you've done many times before and have a good sense of what it takes to complete or the variability is very low, it's disingenuous to say "We have this batch of work and we think it will take 400 hours to complete it." Statistically, you've probably underestimated that work by as much as 100%, maybe even more. It's the cone of uncertainty.

If you want to be truly honest and transparent, you might take a sampling of the work to tackle at first, get it done, then extrapolate from your experience what it might take you to complete the rest of the work. As you work on each small batch of work, you'll get a better sense of what's involved and will be better able to forecast what it will take to complete the remaining work. If there's a high degree of variability, then your best bet will be to break down the work into smaller chunks. Working with smaller batch sizes and working in timeboxes are two main strategies when working in an agile manner for managing complexity and being able to give better estimates.

While I totally agree to this, I just wanted to get a rough idea on how the rough estimate is derived.  It may need not be near the actual but the management must be making a plan based on it on the approximate number of sprints (which may surely vary)  but something to begin with as part of planning. There would be something like planned versus actual. Actual will always be different from planned but there must be some planned to begin with.

[Campbell Ritchie]

Satyaprakash Joshii wrote:. . .  I just wanted to get a rough idea on how the rough estimate is derived. . . .

Take the budget, divide it by a develope's salary, and divide that by number of developers.

Well, that is probably more scientific than any other way to estimate it

[Junilu Lacar]

Well you can set an arbitrary time box and plan to deliver whatever work you get done within that time. It's fine to have an initial estimate using the technique you gave but you should also plan to adapt your plans based on what actually happens as you complete each sprint.

That's why the preferred term now is "forecast" because it's really a lot like how meteorologists try to give people an idea of what's going to happen. Forecasts are much more reliable as you get closer to the actual date. If you have a 30-day forecast, what you think might happen 30 days out might be very different from when you get to 10 days out or 3 days out.

[Junilu Lacar]

The problem people always run into is that they get tied down to those initial "estimates". That is, their initial estimates become commitments. And then when those estimates inevitably vary with reality, developers get blamed for their "poor estimates". If you want to avoid that then it's better to be honest with yourselves and say up front "we think we can get all this done based on what we know now but that could change as we learn more. Make your plans accordingly."

[Junilu Lacar]

This is really a big topic that gets you into things like value streams, bringing the work to teams, agile budgeting and finance (fund teams and value streams, not projects) and a whole slew of other aspects. Time boxes, small batch sizes, planning and replanning around evolving forecasts, these are all just a small part of a large complex picture.

[Dave Tolls]

Satyaprakash Joshii wrote:

While all members will contribute to the time to be taken, I think the time to be taken depends most on the developers who are doing the coding (more than the one doing QA, dB etc).

Unless you have a lot of testers, I think, under the balance I usually encounter, you'll find the time taken is mostly defined by the testing.

[Junilu Lacar]

I was holding off but since Dave broached the topic, I have seen a number of organizations who do a lot of testing at the system level, mostly manual end-to-end even for things that ought to be tested at the unit/module/component integration level. These kinds of organizations tend to have way more testers and much longer test cycle times. This is also where you'll see such antipatterns as a sprint for development, a sprint for testing, a sprint for hardening, and maybe even a whole sprint to deploy. That is not agile, of course. So the estimates that developers give are really what is traditionally called "code complete" effort.

[Satyaprakash Joshii]

Junilu Lacar wrote:Well you can set an arbitrary time box and plan to deliver whatever work you get done within that time. It's fine to have an initial estimate using the technique you gave but you should also plan to adapt your plans based on what actually happens as you complete each sprint.

That's why the preferred term now is "forecast" because it's really a lot like how meteorologists try to give people an idea of what's going to happen. Forecasts are much more reliable as you get closer to the actual date. If you have a 30-day forecast, what you think might happen 30 days out might be very different from when you get to 10 days out or 3 days out.

Perfect advice.

[Satyaprakash Joshii]

Junilu Lacar wrote: If you want to avoid that then it's better to be honest with yourselves and say up front "we think we can get all this done based on what we know now but that could change as we learn more. Make your plans accordingly."

Yes that is something every developer must learn some day in his career.

[Satyaprakash Joshii]

Junilu Lacar wrote:This is really a big topic that gets you into things like value streams, bringing the work to teams, agile budgeting and finance (fund teams and value streams, not projects) and a whole slew of other aspects. Time boxes, small batch sizes, planning and replanning around evolving forecasts, these are all just a small part of a large complex picture.

Yes and I know it is the work of higher management but by getting a rough idea about how it happens I feel more confident. When things happen around us and we have no idea of how it happens, it appears like some rocket science. but when one has a rough idea of how things take place in an IT organization, one feels nothing is rocket science and feels more confident.

[Satyaprakash Joshii]

I think below is one sample sequence of flow of events during agile project:

1. Sales team tells Delivery manager regarding a new project.
2. The delivery manager decides which resource are available to handle this project (which project manager, developers, QA). Say let us assume he creates a team of 7 members out of which 4 are developers 1 QA, 1 team leader, 1 project manager.
3. He asks the project manager about a rough estimate for the project.
4. The project manager discusses with the team leader and asks him to give a rough estimate. The team leader says he will analyze and get back to him on this later.
5. The team leader say feels this work can be done by an average member of development team in 400 hours.
6. He knows that since developers will be only say 6 hours productive in the day instead of 8 hours it will take 400/6=66.67 days for 1 developer.
7. He knows that since there are not 1 but 3 developers so it will be approximately 66.67/3 = 22.23 days to do this.  
8. He knows that he has to add buffer, so he adds some buffer say making it 22+8= 30 days.
9. He sends this rough estimate to the PM.
10. Say the sprints are to be of 10 day each, the PM and Delivery manager plan this accross 3 sprints.
11. They add a sprint 0 and a sprint for production deployment (although the code should be deployment ready at the end of previous sprint itself).
The sprints planned are : Sprint 0, Sprint 1, Sprint 2, Sprint 3, Sprint 4 (production deployment).
12. Suppose this way the work was to be finished by 15th Jan,  they put some more buffer and add one more sprint and communicate to the client that it can be done by 31st Jan.
13. The project manager forms a team from all the team members given to him.
14. During the sprint 0 the data model gets ready and any initial code setup. During Sprint 0, the project manager adds user stories to the sprint for future sprints.
15. Team starts working from Sprint 1 onwards and daily standup meetings are conducted where each resource tells what he did today, what he will do tomorrow and any roadblocks.
16. During the first day of every sprint, the scrum master (who may be a non technical person) plans the Sprint user stories the team can take for the current sprint. This may be based on the priority items of the customer.
17. The team leader coordinates with the team , helps them resolve any issues which they encounter and reviews their code.
18. The code is given to QA atleast few days before end of sprint.
19. The QA creates list of bugs some of which may be taken up in current or next sprint.
20. The team gives demo to the customer on say the last day of the sprint and before the start of new sprint project manager plans for the next sprint.
21. In the next sprint the team takes up new user stories in the similiar way. They also take anything pending from previous sprint for some reason and also any pending bugs.
22. Client may add new features to be included. Also the sprints may not go as per plan. Due to such reasons it may take additional number of sprints to complete.
23. Finally the code is deployed to production.
24. Kudos email is sent from the delivery manager saying that client is happy with their work and thanking the team.
25  Developers are released now for different project. One or two may be kept for any pending bug fixing.

[Junilu Lacar]

Yeah, that's quite frankly a description of a non-agile work environment/flow using agile terms. Just because you use terms like Sprints and Scrum Master doesn't mean you're agile, especially not with what you described. There are so many things non-agile there.

To point out just a few:

1. Agile teams are long-lived so they can go through the different stages of team development (forming, storming, norming, performing). An Agile team doesn't form around a project, then disbands when the project is done. That would be horrific and decidedly non-Agile.

2. "The code is given to QA atleast few days before end of sprint." This is waterfall, not Agile. QA is involved early. QA helps write tests up front, to guide development and design.

3. "The team gives demo to the customer on the last day of the sprint." Sure, they can do that but they should also be engaging with the customer as they incrementally build and design. The sprint demo should not be the first time the customer sees the software. Ideally, you have a customer or customer representative on site and always available to give feedback and comments throughout the sprint.

4. Sprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.

5. The Scrum Master DOES NOT plan the Sprint user stories that the team can take. It's THE TEAM that looks over the stories and pulls however many top priority stories they think they can complete.

I could comment on how many of the other points you listed are non-agile practice, too, but the above should be enough to show that if you're working that way, you're still very far from working in an agile manner.

[Campbell Ritchie]

Satyaprakash Joshii wrote:. . .
6. He knows that since developers will be only say 6 hours productive in the day instead of 8 hours it will take 400/6=66.67 days for 1 developer.
7. He knows that since there are not 1 but 3 developers so it will be approximately 66.67/3 = 22.23 days to do this.  
. . .

Remember that development doesn't follow the usual rules of arithmetic, so your 22.2 will be miles out.

[Junilu Lacar]

Ok, I'll point out a few more indicators of a non-Agile mindset:

1. "The delivery manager decides which resource are available..." -- Referring to people as "resources."

A great deal of the variability in software development comes from people. People are not robots. Their ability to complete tasks may vary from day to day, positively or negatively. If you're stressed or distracted by things like a pandemic, for example, then the 6 hours of productive time you had last week may not be enough to produce the same kind of output this week. This is why I like mobbing, because it often helps even out the team's pace so that when one person has a bad day, another person might be able to pick up the slack. Again, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.

2. "The project manager discusses with the team leader and asks him to give a rough estimate" -- Again, it is the TEAM that estimates the work they are taking on, not just the team/tech lead.

3. "... each resource tells what he did today, what he will do tomorrow and any roadblocks". First of all, that's a little off. It's "What you did yesterday, what you'll do today, and what's getting in your way." I don't favor this format for the standup meeting anymore because it quickly leads to the daily standup becoming a status meeting. The daily standup is supposed to be a planning meeting, where people can synch up on the work that they need to complete and decide who needs to collaborate on what, who needs help on what, what is done, and what is going to be worked on next. When each person only talks about their status and nobody is planning to collaborate or help another person on the team, it's most likely you don't have a team at all but a group of people who are working individually on their own thing. This often leads to one or two people becoming the task master / foreman / coordinator / whip cracker. Not Agile.

Here's how I like to run daily standup meetings: The team gathers around the board (a physical board is still the best). Starting from the right side, we work our way to the left, from DONE, DOING, to TODO. That means we focus on the cards that are closer to getting DONE first because these are the "What we worked on yesterday" cards. If something got done the previous day, we move it from DOING to DONE if we hadn't already moved it. I say "we" but there's usually someone leading the conversation around each card. That would be the owner of the card. However, since we're collaborating on each story, there are multiple people involved in the work needed to move a card.

If there are any cards that are blocked from going to DONE, we talk about it and decide who needs to collaborate to unblock it. This is the "What's getting in our way?" discussion. Otherwise, we move to the DOING column and talk about the cards that are still there. This is part of the "What are we doing today?" discussion. If we have capacity, we talk about the next card we're going to pull from TODO to DOING. If there's something that's keeping us from pulling a card to DOING, we again talk about how we're going to unblock it.

The main difference here is that we don't go around the circle and let each person talk. The focus is not so much on each person but on each card that's on the board. We focus on the WORK, not the WORKER. When we leave the standup meeting, we all have a shared understanding of the progress we've made so far, the blockers we have to deal with, and the work that we're going to collaborate on for the rest of the day. This is what working as a team is all about.

[Jeanne Boyarsky]

Junilu Lacar wrote:A great deal of the variability in software development comes from people. People are not robots. Their ability to complete tasks may vary from day to day, positively or negatively. If you're stressed or distracted by things like a pandemic, for example, then the 6 hours of productive time you had last week may not be enough to produce the same kind of output this week.

My team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc). We then add up the available hours per sprint and do so math to estimate the number of story points we can commit to. (The math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.)

I like that you mentioned distraction. We gave each team member the option for next sprint to further discount their time ("pandemic tax"?) if they felt they are less productive than usual. Three of us took up that offer. (This is our first full sprint since conditions devolved locally).

I like that we are doing this. It reflects reality and allows us to commit to something that's practical. We are still working on the most important tasks/stories. And it reflects the fact that how much we got done in the last three sprints isn't the best predictor for how next sprint will go.

[Dave Tolls]

Junilu Lacar wrote:I was holding off but since Dave broached the topic, I have seen a number of organizations who do a lot of testing at the system level, mostly manual end-to-end even for things that ought to be tested at the unit/module/component integration level. These kinds of organizations tend to have way more testers and much longer test cycle times. This is also where you'll see such antipatterns as a sprint for development, a sprint for testing, a sprint for hardening, and maybe even a whole sprint to deploy. That is not agile, of course. So the estimates that developers give are really what is traditionally called "code complete" effort.

I wasn't thinking of that sort of testing.
I was thinking of the writing of automated integration tests.
They tend to take longer than the writing of the code.
And by "tester" I was thinking about people wearing a tester hat while doing that.  The job is fluid, though you may have one or two dedicated testers/QAs on the team to sanity check things (I'm of the opinion that many devs are not great at that sort of test writing and having someone around with the right mindset helps immensely).

[Junilu Lacar]

Dave Tolls wrote:I'm of the opinion that many devs are not great at that sort of test writing and having someone around with the right mindset helps immensely.

I don't think its that devs are not great at that sort of thing, it's that they are seldom pushed into that kind of work so they don't get a chance to get good at it. My SWAG (semi-scientific wild ass guess) is that only 10% of developers practice some form of test-driven development -- the rest are just nose-down, bang it out coders who leave it up to testers to find issues. If you read between the lines of what OP wrote, their development teams are probably like that. When I do TDD, integration is part of the testing that I do as a developer and that's done very early on in the design process. When I'm done coding and unit testing, integration testing takes very little additional time.

[Satyaprakash Joshii]

Junilu Lacar says

The main difference here is that we don't go around the circle and let each person talk. The focus is not so much on each person but on each card that's on the board.

That is a good point to understand.Thank you.



Junilu Lacar says

An Agile team doesn't form around a project, then disbands when the project is done.

If not this than what is the other way suggested?


Junilu Lacar says

Again, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.

Agreed. How does one bring these out( own perspective, skillset, and experience) during the daily meeting? In terms of DONE/Doing/TODO and any inputs if anyone has ?


Jeanne Boyarsky says

The math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.

While the team member working on a task will estimate whether the task is easy/medium/complex, how are the story points mapped to the number of hours.  
Also, how is it done for the first sprint where there is no historical data?



Junilu Lacar says

The team gathers around the board (a physical board is still the best). Starting from the right side, we work our way to the left, from DONE, DOING, to TODO.

I think apart from these there is one more thing. In case some user story planned for the sprint is not on track to get completed in the sprint, that also has to be brought out in the discussion as a risk.



Junilu Lacar says

Again, it is the TEAM that estimates the work they are taking on, not just the team/tech lead.

I did not say this for the Sprint , I said for the initial rough estimate of the project duration (e.g 4 months). Here all members may have different opinion (5 months,3 months) but someone is required to have a final say and send it as 4 months.


Jeanne Boyarsky says

My team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc)

Availaility for 40-(4% of 40) hours in the week. I think that it means out of 40 hours the team members would be 36 hours productive which comes to 36/5 around 7 hours

a day.Since you talked about further discount then I think it can be around 6 productive hours a day.


Junilu Lacar says

"The code is given to QA atleast few days before end of sprint." This is waterfall, not Agile. QA is involved early. QA helps write tests up front, to guide development and design

I meant that QA will straight way start writing the test cases based on the user story but running those test cases will happen once that user story is completed.


Junilu Lacar says  

Sprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.

In my company we have a practice of sprint 0, so was never having an idea that it is a waterfall practice instead of agile. Some tasks like installation, setup , getting access etc are done in Sprint 0. So when would these be done in agile if there is no sprint0?




Junilu Lacar says

3. "The team gives demo to the customer on the last day of the sprint." Sure, they can do that but they should also be engaging with the customer as they incrementally

build and design. The sprint demo should not be the first time the customer sees the software. Ideally, you have a customer or customer representative on site and

always available to give feedback and comments throughout the sprint.

Agreed.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:
Junilu Lacar says

An Agile team doesn't form around a project, then disbands when the project is done.

If not this than what is the other way suggested?

You form a team. You work on a project. Then you work on another project with the same team. Then guess what, you work on another project with the same team.

Yes, people come and go. But having one person change at a time evolves the team. It is easier to incorporate one different person than for a whole team to gel again. I've been on my current team for over 5 years. We've gone a lot of projects.

Satyaprakash Joshii wrote:
Junilu Lacar says

Again, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.

Agreed. How does one bring these out( own perspective, skillset, and experience) during the daily meeting? In terms of DONE/Doing/TODO and any inputs if anyone has ?

Sally: I'm having trouble with the jQuery widget.
Bob: I have an idea on that. Let's pair after.

Satyaprakash Joshii wrote:
Jeanne Boyarsky says

The math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.

While the team member working on a task will estimate whether the task is easy/medium/complex, how are the story points mapped to the number of hours.  
Also, how is it done for the first sprint where there is no historical data?

Guess. Seriously. You aren't going to be right the first few sprints no matter what you do. One thing my team does (even as a mature team) is plan work both above and below "the line". (The line is a physical line on the OneNote list of stuff in the sprint.) The stuff above the line is what we are committing to as team. For the stuff below the line, we will get some of it done. But no promises on what or how much. This isn't a Scrum thing. It's something that evolved and works well for us. [Our team provides user support as part of our work and has a lot of tasks that depend on people outside the team. If we have a task to help team A with something and team A no longer wants to do it/talk to us/has a production problem, we can do more below the line work rather than replanning. Or if we have a prod problem, we will get less below the line work done. Either way, the stuff we committed to retains a focus.

Satyaprakash Joshii wrote:
Jeanne Boyarsky says

My team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc)

Availaility for 40-(4% of 40) hours in the week. I think that it means out of 40 hours the team members would be 36 hours productive which comes to 36/5 around 7 hours

a day.Since you talked about further discount then I think it can be around 6 productive hours a day.

Also remember to subtract team meetings.

Satyaprakash Joshii wrote:
Junilu Lacar says  

Sprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.

In my company we have a practice of sprint 0, so was never having an idea that it is a waterfall practice instead of agile. Some tasks like installation, setup , getting access etc are done in Sprint 0. So when would these be done in agile if there is no sprint0?

Who says you can't do them in agile. The goal is to deliver something to the customer. In sprint 1, that can be a mock up. Or  you can deploy to a server you already have access to. Or all those admin things can be done before the project exists rather than having a sprint 0

[Satyaprakash Joshii]

Thanks

[Junilu Lacar]

Jeanne Boyarsky wrote:Or all those admin things can be done before the project exists rather than having a sprint 0

Exactly! The idea that you can't do any work unless it's "defined in a sprint" is totally missing the point of the idea of a "sprint". A sprint is simply a small timebox within which you try to deliver an increment of value. It is one iteration in a series of iterations that make up a release. It is a way to plan for and focus on a small batch of work that will hopefully culminate in completing a part of the product that will give some kind of value to the customer. If you're not ready to start working iteratively, then don't start iterating!

Think of a release as a for-loop and your "sprint 0" as all the statements you execute to set the context before you actually enter the loop.

// Initialize things you'll need in the loop -- i.e., "sprint 0"
List<Stuff> deployable = ...;
int teamMembers = 5;
... // other stuff needed inside the loop

// release planning: 5 sprints
IntRange release : rangeOf(1..5);

// now start sprinting!
for (int sprint : release) {
    List<Story> backLog = ...;
    backlog.add(planSprint(productBacklog()));
    for (Story nextStory: backLog) {
       deployable.add(workOn(nextStory));
    }
    demo(deployable);
    retrospect();
}

release(deployable);

Why would you artificially jam everything you're doing lines 2 to 4 into a "sprint" -- it doesn't make sense. It's just general stuff you need to do to get ready to actually execute on the sprints.

Don't let yourself become a prisoner of the framework and its constructs. Instead, use the constructs to organize and streamline your planning and improve focus on the immediate work at hand.