We’re rewarding the question askers & reputations are being recalculated! Read more.
15

They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles. Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA. Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it ...


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

Great project management is not about hitting your targets 100% of the time. Much of our performance is probabilistic where many of the drivers of our results are out of control and very random. Missing your targets becomes a problem if it became a surprise for you as the PM and your customer. If you were monitoring properly, such as using critical path ...


9

TL;DR Targets and estimates are two different things. You're confusing the two, and setting your team up for failure. Targets vs. Estimates A target is something you assign to your team, such as "I want this set of tasks done in a month." Management targets are fine so far as they go, but they rarely provide a means to get there. For the actual ...


9

Should developers do QA? I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or ...


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

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

What's Wrong with Your Team's Processes When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline. Your process problems are legion. Let me count at least some of the ways: Your Product Owner should never, ever be assigning work to the team. Your "developers" and "QA ...


7

Project managers manage variances. You will have both favorable and unfavorable ones. It is not a matter of "asking" but rather informing. Planning values that you choose, both cost and time, are single values that live in a probabilistic range of results. For example, your project has an estimate of finishing between three to nine months. You targeted ...


7

This is why I prefer a product oriented WBS. Except when the deliverable is a service, the WBS should be based on the product itself, broken down to its components, and then underneath add activities and tasks. Where you load resources is up to you but I typically load them at the lowest level product WBS. Below this, I could not care less what changes ...


7

Crashing is simply the concept of throwing more resources--be it money, tools and machinery, humans, etc--at a work package in an attempt to decrease its overall duration. The general idea is, if you planned 10 days with one person to do a task, then applying a second person will decrease the duration to five days. The issue is, this does not work that ...


7

TL;DR Like any project, things happen. I am looking for feedback on how to plan for the contingency in a scrum based project. [sic] This is an X/Y problem. In Scrum, you have estimates rather than guarantees, especially at the release-planning level. While you can always apply a fudge factor to any project management methodology, there is no cure for ...


6

You can plan a project without a software tracking tool, you can't plan a project without communication. The tools is just that, a tool. You use it to help you get what you want done. A hammer won't build a house, but it will make building the house a lot easier (using rocks to pound in nails is hard on the hand). And as Zsolt says, tracking tools do ...


6

What you can do: Deal with the risk first: you have identified a clear problem impacting your project so if you haven't done so, formalize risk identification and qualification through your controlling processes/mechanisms (e.g. record the risk in the risk log, evaluate impact/likelihood, assign it to the technical group manager and communicate to the ...


6

The simple answer to "What does the PM do when the milestone passes" is: Re-schedule the project plan to take the delays into account then report on milestone changes back to the project sponsors and stakeholders. It is assumed that the PM would have been raising a risk to the project schedule in the risk log and talking to all relevant people in the run ...


5

The variance here in punishable. That is unfortunate. It is imminent that you will be punished because it is certain that there will be variances. Hoping or trying to have a near zero variance, or zero variance, is to suggest it is possible we can predict the future accurately and precisely...which we cannot. Accurate Estimates is an oxymoron. First you ...


4

TL; DR At various points, your project is potentially 1.5 weeks late or 4 days early. Your methodology values calculated variances, but (as far as I know) doesn't mandate continuous re-planning. It would therefore be more efficient to value communication over re-scheduling. Communication: The Underlying Question? In your question, you state that at some ...


4

The best way in every circumstance will boil down to understanding your client's perspective - including, but not limited to, the extent to which they value time as compared to cost and quality. It's always tempting for the project manager to paint a rosy picture and not inform the sponsor/client of a risk. That is usually the wrong thing to do because it ...


4

The Problem [Are] there any cases...when wrong estimates can be justified? Estimates are not guarantees. They are "educated guesses" based on experience, historical data, and a set of assumptions. If you're being asked to "justify" your estimates, you are already playing the Blame Game™ and starting from a false premise. You can't win the Blame ...


4

To answer your question a generic sense - ALL estimates are wrong. Whether or not deviations are justifiable (or should be compensated) depends on the 'why' they were wrong. To address it in a more specific way - In the beginning of your question you said 'assume everything was done correctly' (i.e.: we were not at fault). Later you said 'we could not ...


4

In my teams all developers would cross-check their developments/bugfixes: Review their code using a GIT pull request, Validate the behaviour by testing it in the browser, Validate the functional behaviour too - if it's illogical, it's the role of the peer to go to the functional expert/PM and check the development still makes sense. It's a great way to ...


4

Funny to read my name in the question. The documentation of this type of purposeful deviation could happen anywhere you normally document. For example, if an issue was identified and documented in the issue log, the recovery plan--a purposeful deviation from method or process--might be documented in the same log. It could be documented in a weekly report ...


4

I've been dealing a lot with a scope creep over the last 2 years. I created a list of things that is a must to keep in mind in order to minimize the negative impact on the project. At first - you should realize that scope creep will happen! You should: know the requirements; know the client's expectations; have balls to say "No". Saying "Yes" to placate ...


3

On a given project, estimates should get better as experience team gains experience with and knowledge of the particular project. This will cause estimate to change. As you break things down you should get better estimates which may or may not be equal to the estimate for the larger package. If there is low tolerance for variance from the estimate of the ...


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


3

it sounds like you are unable to estimate prior to sprint planning or in sprint planning due to the large ambiguity of the requirement. You thus have one of two choices 1) Recognize the fact that the requirements are so ambiguous and that they are impossible to estimate. Thus the team will resolve these as they move along each sprint. i.e. stop ...


3

Manage it through change control due to some changes in the way you do the work and other interventions, you estimate that you can shave off the finish variance and actually come in sooner than planned with a favorable variance of four days. Sounds like a miracle! I recommend a cautious approach. I would hate to communicate an early completion now and go ...


3

By control limits, do you mean an acceptable tolerance for cost and schedule variances? If so, 10% is the typical benchmark, at least commonly accepted with those systems that are ANSI compliant, like in the DoD. In other words, your CAC is acceptable if within + or - 10% of your BAC. You can certainly tighten it up based on your project needs. To keep ...


3

The answers given so far are good. I'd add one thing: treat all estimates as immutable. You never update an estimate. You create a new estimate. There is never "the" estimate. There are "the estimates" and "the most recent estimate". However, since your board have tied estimation to reward and punishment, they have defeated the purpose of estimation ...


3

Project Definition and agreement To be classified as a project, you need to have a defined scope, time plan (incl. milestones and deadline), resources and budget. If the client/customer have a deadline, it must be based upon a scope and a timeplan to start with. Before the contractor (your company) should agree on a deadline, the time plan should have been ...


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