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


13

Definitions Must Be Localized I am using a project management system that forces me to define feature requests as either High, Medium or Low priority. Has anyone got a good set of definitions that clarifies what those priorities should mean? They mean whatever your organization wants them to mean. How any given organization prioritizes features or tasks ...


13

Business Analyst works with the Product Owner and provides him with valuable insights on the value and importance of the user stories, but the PO is still the person who sets the priority of the backlog. The same applies to the the Team's involvement. Team members provide usable information on the technical level to the PO and the PO should be able ...


10

It might even be a stretch to say that business value is the most important factor. Overall, prioritization often comes down to a ROI, but a lot of factors can feed into that, such as: Types of Value There is revenue, but there are many other types of value. Security adds value for many companies, as does other hard-to-quantify items like brand recognition,...


9

Try to quantify (read: put a hard $ amount to) the increased time/expenses that build up over the lifecycle of the project - regression testing, bug-fixing, new feature risk and increased time to integrate, etc. Edit: and of course share this with the clients. :)


8

With my team we recently adopted a new bug-tracking tool based on a criticality matrix. This is a physical board representing a 4x4 matrix on which we stick notes according to two criteria: Columns represent the intrinsic severity of the bug. The more a bug is on the left, the more it is critical. Each column has its own explicit policies but, for example, ...


8

In the same way that a UX designer is responsible for creating an excellent user experience, a Scrum Master is responsible for creating an excellent project experience for those people who use the team to turn their ideas into reality. By looking at the "team" from the external perspective, we can easily narrow down those bits of Scrum that are relevant ...


8

I love defect management, it throws up some wonderful logic problems :) What actually is Criticality? If you could define that then you would know the answer. I believe it is the combination of Severity and Priority, both of which should always be defined independently in defect management. The severity of a defect, i.e. the impact it has on the ...


8

The direct answer is that the Product Owner prioritizes the backlog. It is, of course a little more nuanced than that. In an ideal world, the PO would just sort the backlog items by effort and value to create their priority - and that's usually what happens at first. However, the team is going to provide a lot of input about how the order selected affects ...


7

TL;DR Make unit testing part of your core development methodology, and ensure that test coverage is part of your "Definition of Done." Also, ensure your estimates include the overhead to develop and refactor your unit tests. How to "Bake In" Unit Testing How can I make unit testing a priority? Unit tests can function as both design tools and quality ...


7

The Product Owner has responsibility for the backlog and the development team has responsibility for delivery. However, in Scrum we work as a team and there is nothing to stop the Product Owner discussing concerns over delivery with the development team. Just as there is nothing to stop the development team discussing concerns over the backlog with the ...


7

Product Owner and the Development Team collaborate The Scrum Guide is very clear on these aspects: Product Owner and the Development Team collaborate on Backlog refinement: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the ...


7

I will assume that the "push" approach is not only direct, but also immediate. (Like when someone comes up to you and says "hey, Joe, can we roll this later today?"). The "pull", on the other hand, is not only indirect, providing the queue as the go-between, but also delayed. Tasks might accumulate in the queue, waiting to be picked during the day, or ...


7

So, it looks like, you have two problems: Clear priorities. Delivering various projects in parallel. First one can be addressed by creating a clear list of all features (not tasks!) from different projects you work on -- so called Backlog. And this Backlog is common for all projects. And you set policy that you work on this list from top to bottom no ...


6

TL;DR I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not. From a framework point of view, this is likely to be the correct approach. It's certainly what I would recommend as an organizational statement of policy. It reinforces Scrum processes and practices (e.g. time-boxing), and ...


6

Assuming that all three projects have similar schedules, profit margins, strategic alignments, etc. (which I infer from your question). Which one has the highest risk? I prefer to work on the riskiest project first; the earlier I can refine that risk, the better my chance of successfully managing that risk. Which has the highest re-use value? For which ...


6

Technical Debt isn't a PM's Responsibility: As a project manager, the short answer is, you don't. This is really a job for the technical team, which includes functional managers and the actual developers working on the project. If you're doing project management correctly, then you should be getting all of your estimates from the developers themselves. ...


6

When you think about it a bug tracker is nothing but simple task management application with (a simple) workflow attached to every item. From this perspective it doesn't really matter whether a work item is a software bug, a task to perform or anything else. It means that you should be able to use bug trackers to achieve the goal you define. I was ...


6

Here are some pitfalls I've seen with the MoSCoW model. Managers are worried that their requirements will fall into "should" or "could", and won't get done, so they make up reasons why their requirement is a "must". This ends up delaying business-critical functionality. (This is usually caused by, or exacerbated by, bad KPIs at an organizational level. I'm ...


6

TL;DR There's no "one true way" to organize a Sprint Backlog. A lot depends on the granularity of the stories, the idempotence of each story, and the overarching Sprint Goal. However, I would strongly recommend that Sprint Backlog prioritization be a continual focus within each Sprint Retrospective, so that the team can inspect-and-adapt that process until ...


6

You are solving wrong problem Your PM is completely out of control and #1 task is to get Projects back to PMs hands. They're now run by the Client and Developers, which is not really their job. . There are many dangerous signs in case description: "senior developer promised would be delivered over a month ago". What does "developer promised" mean? Isn't ...


6

TL;DR You have one or more process problems involving communication and prioritization. You need additional information in order to inspect-and-adapt your team's process in a collaborative and sustainable way. Your Problems, Restated You make the following points in your original post: I say they are small requests because they aren't critical issues ...


6

Product Backlogs Must be Ordered, but How is Implementation-Specific As we know, normally, during the prioritization process in agile, business value is the most important factor that taken into consideration. This isn't actually true. A Product Backlog should be ordered, but the order can be based on any factors (or combination of factors) that the ...


5

TL; DR WIFO is really more about risk management than it is about quality management. Depending on your risk model, WIFO may or may not be a good choice. Define "Worst" The first thing you need to do is define "worst" for your use case. Worst doesn't inherently mean something with a high defect or failure rate (although it may); it could also be a measure ...


5

Don't ask, don't tell ;) I guess you're not giving estimates on how much time you spend thinking, and how much writing code, the same principle should apply to unit testing. As soon as your Unit Testing activity becomes a line in the budget it becomes negotiable. I never report unit testing as a separate activity (and in principle most of the time you ...


5

Customer seems to be too busy to do regular meetings often translates into 1 of 2 things: 1) Customer not understanding value of meeting or 2) Customer has more valuable things to do In case 1 education is required with the customer. The customer may not understand the value they provide to the rest of the participants in the meeting. In case 2, look at ...


5

TL; DR Your underlying question appears to be whether the customer, rather than the Product Owner, should be allowed to prioritize the Product Backlog. You are also questioning whether label-based sorting is useful in any way. In short, only the Product Owner (PO) may prioritize the Product Backlog, although s/he is expected to do so with the support and ...


4

It sounds like you're using "Worst" as a proxy for "Most Valuable". One thing that's nice about agile methods is that they tend to order work according to value-to-client, not according to imposing a total project execution order to minimise costs. So you do the most important things first, then the next most important, and so on until there's nothing more ...


4

TL;DR The problem isn't with your bug-tracking tool chain. The underlying problem is a lack of rigor in defining bugs in your business context, and possibly a lack of clarity in the business objectives that your organization is trying to achieve. The solution is to define your terms unambiguously, clarify your objectives, and then build processes (...


4

Scrum is for Teams While you could use Scrum in a one-person shop, Scrum is really a framework that's designed for teams rather than individuals. The underlying inspect-and-adapt philosophy is also available to a one-man shop using Kanban or Extreme Programming (XP); XP in particular is often a great fit when you want agile practices rather than a project ...


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