We’re rewarding the question askers & reputations are being recalculated! Read more.
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, ...


19

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


19

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


16

It seems the root issue here is lack of trust between client and your company. They don't trust you will deliver the solution, whatever it is, according to a general roadmap you have. I assume that you have one. What more they don't trust you know what you do in short term. Basing on what you wrote ("we are losing control over the work to be performed") it ...


13

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


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


12

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


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

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


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


10

Not an easy situation you describe. In my view it is important to stick to someones values. For me this includes telling the truth and insisting on being honest with the customers. If you - as a company - stuffed up the project then it is just a matter of time that the customer will find out. In my opinion it is better to share the bad news sooner rather ...


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

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


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

the backlog is populated by the project manager Scrum, as its defined, doesn't have any 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 importance ...


9

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


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

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


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

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

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


7

Regardless the methodology used for estimates, I wouldn't suggest to have the client involved in the process of estimations. Some further reasons, besides the ones you mentioned: Clear up requirements: Estimation meetings are long enough only discussing about estimates. Discussing the cleanliness of a requirement would only add another level of complexity ...


7

You certainly have a problem. Ultimately the problem is yours, even if the team is composed of total slackers. You're accountable for delivering on time; the team is accountable only to you. I'm not sure that offshore/onshore is relevant; I'm not sure that many of the details above are relevant (except that we would have asked if you hadn't supplied them.)...


7

I'd caution against introducing new terminology, as you'll confuse people that are using User Stories correctly. At most, I might try calling them "Agile User Stories" (or Scrum User Stories if you're using Scrum specifically). Instead, I would counsel you to try to educate those who have the knee-jerk reaction to how the term has been used in the past, and ...


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