23

compare to other colleagues and feel insulted. The other two answers are good - but this confuses me. When I've done stakeholder analysis, the process has been open and participatory. There shouldn't be any value judgement. Power and influence are closely related to budget and participation. If a given stakeholder feels that the graph shows them as less ...


15

I personally don’t like tools you have to hide. This leads to mistrust and if it leaks (for whatever reason) you are in trouble. So we started 20 years ago to use a technique which is called project environment analysis (AKA extended stakeholder analysis). The tool is simple and efficient and is part of the open accessible project handbook and is also used ...


11

shouldn't the adoption of agile values be present on both sides? Yes, it should. But often isn't. The problem is that Agile/Scrum is more of a mindset than a way of working. But people all throughout the organization see it as a methodology for developing software. If you are an executive, a business person, or working in some other department within the ...


9

TL;DR Yes. Stakeholders need to be active collaborators in a successful Scrum or agile process. Roles and Objectives for Stakeholder Collaboration While not spelled out prescriptively in the Scrum Guide, in successful Scrum implementations each role on the Scrum Team is responsible for collaborating with stakeholders in a role-specific way. Product Owner ...


8

Choosing two answers, I would select A and D. B can be eliminated since project plans and formal change request procedures aren't typically a part of agile delivery approaches. Agile Software Development favors collaboration and responding to change over long-term plans. Frequent delivery of working software and responding to change builds a change request ...


3

Like most things, it depends. In theory, you could forecast when work is likely to be done. If you understand your team's average velocity (whether it's in story points per Sprint, ideal hours per Sprint, backlog items per Sprint), you can forecast when you will get to a particular item on the backlog. However, there are a lot of caveats with this. It ...


3

It's best to avoid using group titles like defenders and apathetics. The map in ProjectManagementBlueprint conveys the same stakeholder analysis but without the labels. It also uses the phrase engage and consult instead manage closely.


2

This and other stakeholder analytics need to be tightly controlled and viewed only by those that need to view it. Changing the words can alter the tool's intent and in an unfavorable way. So do it as prescribed and protect it as if your job depends on it. EDIT: Segmenting stakeholders into one category or another is necessary so you know how to ...


2

Honestly, Duncan, I think that you should simply present it to everyone and presume that all concerned are "at work right now" and thinking about the project ... not their fragile egos. This four-square diagram is functional and descriptive, and anyone's free to disagree with you -- if they care in the slightest. Show them this diagram if there is a ...


2

The tool you want is a burnup chart. JIRA has them built in as Release Burnup Chart or Release Forecast Chart (they keep changing the name), but the feature in JIRA is limited that it only forecasts the whole release. However, you can build these charts by hand - they may seem difficult at first, but they're very fast and very easy once you get the hang of ...


2

You are right to be concerned about how the chart would be perceived by your stakeholders. The best answer, in my opinion, is to not publish it - there's no rule stating every document you produce has to be provided to the project team. This document is meant to be an analytical tool so you, as a project manager, can make decisions on how to handle each of ...


1

Are timelines non-agile/-SCRUM or should a timeline be always possible for tasks that are months in the future. You can always do a long(er) term release planning no matter if you use Scrum or anything else. You basically look at the features you want done, estimate each and every one of them, then knowing the team's velocity and the length of a sprint in ...


1

Stakeholders certainly ought to understand and adopt an agile approach. To use Scrum effectively stakeholders need to appreciate the significance of product ownership, continuous delivery and prioritisation since they are things that decide the outcomes and define the way the business collaborates with the development team. Agile adoption is often driven by ...


1

Key aspects of a task list I am seeking recommendations on how to manage an individual (my own) task list or how best to create a work management plan. Identify urgent vs important tasks: Urgent tasks tend to crowd important tasks to the background. Deadline: When do the stakeholders say they need it. Delivery commitment: When are you able to deliver ...


1

One of the challenges that Agile faces is that it's rare the whole organisation is Agile, particularly if you're operating outside of the tech/startup universe (and, to be fair, within in too). So in almost every agile team, you're going to butt up against non-agile ways of thinking and working. Those different ways of thinking are going to be a source of ...


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