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

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

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

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

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


8

In Scrum, you should not see the distinction between "developer" and "QA tester". As of November 2020, the Scrum Guide says: Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. A Scrum Team has one Product Owner, one Scrum Master, and ...


7

The other way is to build trust. Your colleagues need to realize that the kind of planning they want to do is simply impossible and an outdated method of working in most cases. Gantt charts only work when the work to be done and the burn rate are very predictable. Neither of them is in software development. There is a better way of navigating these ...


7

Story points and ideal hours serve completely different purposes and are not comparable in any way. Story Points They are part of a double estimate. The capacity of a sprint is estimated in points ("How many stories of small size can we fit in these two weeks?"), and the stories are also estimated in points ("How does this story compare to ...


7

Take a more proactive approach to dealing with technical debt In one of my previous projects, we had a major part of a site run on annual data put together by the business. Unfortunatley, the database had been architected in such a way that each year's data will go into a separate database. When it came time to launch the current year's data, it needed a ...


7

Look for ways to deliver limited business value initially ...even if it is not something that you can actually use. Taking your example, if you are going to accept Visa, MasterCard and PayPal, you can first implement PayPal (or whichever is easiest to implement) and then have separate stories to add Visa and Mastercard. If you are going to accept ...


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