23

TL;DR Much of Scrum's value to an organization is in creating transparency. 100% agreement isn't the real point of planning poker; the goal is actually to narrow the cone of uncertainty around feature estimates as much as possible, and to make the level of effort and potential project risks of each story visible to stakeholders through their chosen proxy, ...


22

I'm going to pick on @jmort253's answer, because I disagree. ROI initiatives aren't the only kinds of project, nor should they be. Chris Matts (the analyst behind BDD, Feature Injection and Real Options) found that 80% of one of his CIO's projects were concerned with protecting existing customer revenue, rather than trying to increase it - essentially, ...


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

Since there doesn't appear to be many specific solutions to this problem, I ended up writing a simple web app that meets my needs. I think that even co-located teams might like to use it. Check it out here: http://www.pointingpoker.com


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 don't think PM methodology is relevant, more what your company's accounting practices are. I have worked with companies that do consider PM as a billable resource and track hours etc to pass those costs on to the client transparently. I have also dealt with subcontractors where PM effort is rolled into overhead so it isn't as transparent. I have also ...


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

No Invisible Work, Ever! Work is work, whether it's on bugs or new features. Therefore, all work needs to be tracked on the Sprint and Product backlogs, regardless of the source. If you are using Kanban, it is certainly possible to have a separate queue for bugs vs. new work, but unless you have separate development and maintenance teams, it doesn't matter: ...


9

TL; DR You actually have two questions. One is about time-boxing, and the other is about estimation. Time-boxing and estimation are the very essence of Scrum. If you aren't adapting those two practices for your team, whatever you're doing isn't really Scrum. Tools and Practices Aren't Silver Bullets [Incremental development] just doesn't seem to bring ...


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


8

I won't make a difference between user stories and issues. The product owner should know whether new features or issues are more important, and should put them into the right order. With this approach you don't have to bother with batteries or velocity, because they are part of the daily work. Based on my experience teams need about 1-2 months to get used to ...


8

User-Visible Functionality The goal of a sprint is usually to complete one or more user-visible features. However, there are certainly projects where this is not always possible. It may be worth re-evaluating whether this is possible in your situation. For example, math certainly supports the concept of sub-expressions, so each sprint could have a goal of ...


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


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