25

It seems to me that you are trying to fill each sprint to capacity, and keep everyone fully utilized. Planning for 100% resource utilization is a bad idea. You will only end up with busy people and delivery will suffer. The point with Agile and Scrum is to deliver value. One QA tester to five developers can quickly turn into a bottleneck while work moves ...


20

You might tackle it by highlighting increases in development costs caused by technical debt. That is a problem we are facing right now, too. Business is requesting more and more features they need when my team really wants to remove technical debt. We underlined that with less technical debt new features can be shipped way faster- and faster means cheaper. ...


17

EDIT: First off, you have a bigger problem. The team that I've taken over doesn't currently do retrospectives or sprint reviews sadly. You may have tagged the Question as scrum, but you're not doing Scrum. Before you try to fix any of the numerous issues that pop up as you try to implement your Scrumbut, you need to first try Scrum by-the-book. If you don'...


15

Does Scrum take into account interruptions? Scrum does not. The Scrum team does. Scrum teams are self-organized and plan their own work. If part of that work consists of fixing urgent bugs from production or handling requests from other teams, then the team needs to find a way to organize around that, how exactly depends on the context: they might ...


15

One possible approach you could consider is using the surplus developer time to create automated regression tests. In the long-run this will give you better automated test coverage and will reduce your dependency on manual testing, helping to alleviate this kind of problem in the future.


14

TL;DR Spikes are estimated in story points. Tasks related to the spike should be estimated in time units. The time-box for a spike is calculated based on the associated tasks defined on the Sprint Backlog. What Spikes Are For [H]ow do you timebox spikes using story points? [They are a] mix of effort and task complexity. You left out "uncertainty." ...


14

100% user story completion vs 100% productivity Think in terms of value delivered vs utilization. Goal of Scrum team should be to maximize output and not maximize utilization. Anything (whether a machine or person) working on 100% capacity for longer duration will eventually break. The goal of Scrum is not to achieve the highest resource utilization; it ...


13

As the PM, you need to make a power grab play; build a case with your management that, as the PM, you need to have the authority to move resources around, including changing them out, in order to increase the likelihood of success. However, accept that fact that you may not get the power you need to really run the project. Many of us are in that very same ...


13

Forget what you have and start with a retrospective There is little point in pushing any tools, process or framework unless people are bought in to their use and the reasons behind their use. Book a retrospective with the team and talk through issues. Chances are, if you don't think things are working as well as they could be, other people feel the same ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

What you need is a hammock task. A Hammock task is a task that depends on other tasks for both the start and finish dates. Like a hammock, the length of the task depends on the space between the two other tasks. Roughly speaking, create a task, then link the start of the hammock task to the first task, and the finish of the hammock task to the second task. ...


12

Not surprisingly, I hear that question a lot. The basic problem with the question is that Agile disagrees with the fundamental idea of a fixed-scope/fixed-timeline project. In the question you were asked, there is the assumption that the end date of a set scope is knowable and the problem is that we are bad at knowing it (estimating). That's not really true. ...


11

No guarantees on this one, but here is what I would try: Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the ...


11

By definition, what you are describing, is not a project at all - because it has no defined beginning and end: A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. ~ PMI There are, however, a few ways to turn this concept into a project(s). One would be to create a backlog of items from bug ...


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 ...


11

Tasks that are not listed increase context switching. People have to keep them in mind, but they forget. Then they remember about them in the middle of another task and think to themselves "Oops, I almost forgot, but I need to keep it in mind. What else did I forget?". This draws brain power away from the actual task at hand. All this may repeat multiple ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


10

I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard ...


10

the backlog is populated by the project manager Scrum, as it's defined, doesn't have a role called "project manager". There are only three roles - Product Owner, Scrum Master, and Development Team. The Product Owner is responsible for maintaining the Product Backlog. and can contain entries as abstract as he wants, with various degrees of ...


10

TL;DR Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work. Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you ...


9

Points Story points are a way of measuring effort using relative sizing. They are deliberately not time based for several reasons including: People are naturally better at relative estimating than they are at absolute estimating Time-based estimates have an influence on the way people do the work (e.g. "The estimate was 2 hours, but I have taken 3 hours ...


9

TL;DR Scrum is an empirical control process, and therefore "big, upfront planning" is intrinsically an anti-pattern. But Scrum certainly includes a lot of iterative and just-in-time planning, along with a predictable cadence and a set of inspect-and-adapt events when the framework is properly applied. Scrum Uses Iterative, Just-in-Time Planning ...


9

Estimates are a tool that supports planning. Anyone that needs to make decisions and build plans about the future can use estimates as a tool to make predictions and figure stuff out (without knowing for sure, you can only estimate; but having an estimate - any estimate - is sometimes better than not knowing at all). So for example: upper management can use ...


8

Scrum of Scrum meetings should handle dependencies between teams It is not recommended to have planning meetings with multiple teams together. With such a large number of people, team members won't be able to pay attention, as you are finding out. For coordinating cross-team dependencies, you can have separate scrum of scrum meetings. Please see more on this ...


8

The It depends pretty much answers all of your questions because they really depend on the context. My first advice is to change your questions by adding the why do I to the beginning. For example, "Why do I want to have one meeting per week?" Because I have to write a report once a week to my boss? Or, because I would like to know about the daily life of ...


8

When projects and project managers are out of sync, this is an issue at the organizational level. The organization needs to resolve this problem if it chooses to advance in its project management maturity level. That said, it is quite common. Usually, you see this question from the PM point of view, who is trying to ensure its matrixed resources are ...


8

You're starting in a quite common environment. 6 people in production, no quality assurance people, several concurrent projects. And, let me guess, you've got ASAP requests pretty much every day. Here's what you should do first: Sort out your development (new features) and suport (bugs, changes) projects. Now separate your production team across ...


8

If I've interpreted correctly, your Question is how to convert Story Point estimations for User Stories into time-estimations for each individual developer. My answer? Don't. The only possible reason I can think for why you would need individual estimates is for individual KPIs (Key Performance Indicators). Which, in my experience, are themselves harmful. ...


8

Sorry, but that is not what the article says at all. The purpose of measuring the past is predicting the future and no one in that threads claims different. What is claimed though and I absolutely agree is that you should not predict the future in absolute, precise, single values. If I go from one city to the next by car, I will say "I'll be there in 2-3 ...


8

What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional. Honesty is the best. You don't necessarily need to mention vacation, but being up front that, due to circumstances, the work will not be completed as originally ...


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