11

TL;DR In general, I recommend a "fudge factor" of 0.75 to baseline a new project, absent other data. This would mean 6 hours of project effort in an 8-hour day. I also recommend a more aggressive fudge factor of 0.4 to 0.6 for new teams to account for the overhead of team formation and process development. In the following sections, I describe some ...


11

TL;DR Slack is essential, but an excess of wasteful idleness is not. True leadership is being able to tell the difference. Scrum Roles and Story Commitments The Product Owner prioritizes the Product Backlog, but only the Development Team may estimate stories. The team uses these estimates, along with their estimated velocity, to determine how much work ...


9

It is a common agile practice to reason in terms of story points instead of hours. You can learn more about why we do so here. The velocity concept, instead, is well explained in this blog post. I don't want to complicate things, so I will answer to your question speaking in terms of hours. Let's imagine that you are on the first iteration with a brand ...


8

How to Plan for Unplanned Absences People get sick, scope changes, and stuff happens. That's why velocity should always be measured as an average or a range, and primarily used as an upper bound on work selected for a Sprint rather than a target. If you have sufficient slack in your Sprint Planning, a couple of sick days will not put your Sprint at risk. ...


6

One other thing you could look at is past sprint variability. If, in the last 5 sprints (assuming nothing like a holiday is really skewing your numbers) you have an average of 35 points and your high and low are 39 and 33, you're probably fine with the things you mentioned. On the other hand, if you have that same average and your high and low are 45 and 20, ...


5

I'm deducing that your team uses story points for an initial estimation then, at the planning meeting, breaks stories into tasks and estimates them at the hour level. First, some general suggestions: Never schedule 8 hours a day. Interruptions happen. Only schedule about 6 hours a day for development tasks. Make sure you're removing those planned days ...


5

You have several options. None of them are exclusive to Kanban though. They all work perfectly fine with Scrum too. Story Points (start where you are!) Avg. Number of Cards Done / time unit (avg throughput) Cycle Time & Lead Time Remember, Kanban isn’t a project management methodology. It’s a continuous improvement methodology. Change things as ...


5

Here are some things that we've found that help with this situation. Of course this relies on our definition of tester and developer, which may differ from what those roles do where you are. Ensure stories are being appropriately sized. It is easier to avoid the problem you discuss if your stories are truly stories rather than epics disguised as stories. If ...


4

Scrum expects cross-functional team members, when developers do not help with the testing part of product backlog items, then they are not cross-functional. Everyone should focus on getting work done, its a team effort. I get the feeling you guys are doing "Mini waterfall" in short iterations and pushing testing to the end. Its hard to turn around a culture ...


4

TL;DR Estimate your team's capacity as an aggregate range based on historical performance, rather than as a sum of the ideal hours available to each individual. Furthermore, you should carefully consider what you hope to accomplish with such a calculation, and determine whether a more agile approach to productivity and statistical estimation might not be a ...


4

The Scrum Guide says this on the things to take account of when determining the commitments for the next sprint. The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for ...


4

How can I identify the likelihood of the sprint being still completed using this new information? The team should handle this during the first stand-up, or a soon as they notice someone is sick, but let them self-organise. Maybe assist them with questions like: Can we complete the work partially finished by this developer? Will we make the Sprint goal, ...


3

Velocity and Capacity 20% of the team left during the particular sprint. Does the velocity change? It is likely that your velocity will change because the team's capacity has changed, but a lot depends on the work that the team has planned for the Sprint and the cross-functional composition of the team. As a rough planning value, you should probably ...


3

It seems evident that you have a trust issue with your team. You can't say a team undercommits unless you disagree with their capacity planning. Do you estimate sprint capacity? If you think your teams can deliver more points you can certainly argument that at the planning meeting, however you can't expect the opinion of one person to be considered the "...


2

I think Waterfall / Agile methodologies are being confused here. Testing should be completed after each user story is completed and not on a specific day of the week. This sounds more like the Waterfall methodology. If there are elements that are less important the product backlog should be groomed and prioritised by the end user. I'm sorry I would ...


2

This is a very common problem with Scrum. The only way to completely eliminate this issue is to switch to Kanban :). Some ways to alleviate the scenario you describe are: Mix and match the stories within your iteration so that it contains a number of different sized stories. This helps ensure smaller stories can be checked in sooner allowing testing to ...


2

80% is the figure I have always heard, although trying to find internet citations that support that figure is surprisingly difficult and, in fact, I wasn't able to find any! I have flip-flopped in how to manage this within the sphere of project planning and scheduling. If you are using MS-Project then, on the surface, it seems obvious that you would set the ...


2

My answer and some associated comments (1, 2, 3, 4) appear to have sparked this question. The original question presented a very specific case - a Scrum team has met their Sprint Goals before the timebox for the Sprint has elapsed. All of the forecast work has been completed and meets the team's Definition of Done. The team is now wondering what they should ...


2

When the whole team is planning their next sprint, slack should be built in for sick leave, meetings, fixing live incidents etc. Over the course of a year, assume most people will take around half of their sick leave, do meetings and have to work on unplanned incidents. Your velocity should tell you how much the team can achieve in a sprint. I would not try ...


1

You may be conflating two term here - velocity and capacity. Velocity is only measurable after the sprint and will most certainly be less for this sprint because you are short 2 people (by 20% left I'm assuming you mean that two people are on vacation or are in some other way not available). Capacity, on the other hand is more of a prediction ahead of time....


1

TL;DR In Kanban, you generally aren't measuring "team capacity" because kanbans track queues, not people. The closest you are likely to come to a direct capacity measurement in Kanban in the WIP limit, which sets a capacity limit on each queue within the system. While similar, this isn't interchangeable with the notion of team capacity as used by time ...


1

The best suggestion I would offer to anyone asking this is to ask each team member individually what they want to sign up for. Check in weekly to see if there are changes they want to make to this going forward as their default or on a "I'm at 0% since I'm on PTO" type of feedback. There are a few reasons for this: Gets the individuals bought into the ...


1

There is a lot to unpack in there. The way I read the answer and associated comments, I interpret it as one team helping another gives the team the false impression that they can do more work than they truly can. He isn't wrong, but I would expect the teams and the Scrum Master to mitigate this. So if the team tried to commit to a same-sized or bigger goal ...


1

Try adopting the LEAN idea of 'waste' Get the team to record their hours against tasks, meetings, admin etc so that you can work out exactly how much time you are spending on 'non work' tasks each week. This will give you both an average percentage of 'waste' time which you can factor into individuals capacity AND enable you to identify stuff that you can ...


1

Although, this tool would sell like crazy, it won't be able to handle exceptions and variability (I believe it won't be able to handle vacation period, which is not too complicated for humans). Moreover, some would take its output as something written into stone and not a forecast. If you are looking for something more scientific or semi-automatic you may ...


1

There is a contradiction here, you don't use hours in terms of velocity. When you are estimating stories they should be done in terms of story points. These are typically Fibonacci numbers and stories should be sized to take into account effort to do, testing time, testing complexity, risks, unknowns etc. So you could have a story where development may ...


1

Weird to answer my own question, but the problem has been partially solved and I wanted to share the approach the team took. First, we convinced some well-respected senior manager in the company to have a look on the circus going on with the top-management reporting and a to have look over the number. He finally raised his voice to stop the mess, without ...


1

In my opinion, the following factors decides the stories to be included in each sprint. Product long term vision Product owner prioritizes the user stories in advance as per the requirement from the client. This decides the list of stories to be considered in an order. Development team estimate the user stories considering the development effort. Of ...


1

The key to not having this sort of problem is in determining the estimates right. One way to have reasonable estimates is to take estimates from each field expert and reason why he or she thinks so. Thereafter taking all points in consideration estimate a time frame in consensus. For example, if there are three members for taking care of Web-services, all ...


1

Team decides. Product Owner cannot decide this. Product owner only prioritizes. How does team decide? First time just a guess/common-sense. Second time(sprint) history(20%) + guess(80%). Third time history(40%) guess (60%). And there comes a time when history decides(90%) and common sense(10%). This is the best you could get. Tip: In the sprint planning ...


Only top voted, non community-wiki answers of a minimum length are eligible