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 ...
13
If you are building a product for a client, your internal testing / QC work is not subject to negotiations. It is part of the work, part of the price, and there is no reduction in that area. If the client does not want to conduct UAT, that's their choice and risk to accept; however, there's secondary risk on the seller in this scenario. To mitigate the ...
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
I would ask myself a fundamental question: If I don't have stakeholders, who am I building this product for?
In your situation, it sounds like you're building it because the owner of the business, your product owner, said so. No problem. In other words, your product owner isn't representing stakeholders, he is your stakeholder. Cool!
But there's a catch. ...
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
Management Owns Cost-Overruns
A Developer estimates between 70 to 100 hours for a task. Due to the urgency of the task and the developer's unavailability, a far less experienced developer is assigned to the project. The new developer takes 200 hours to complete the task.
This is the agency's responsibility 100% of the time. Whether the estimate was wrong,...
8
First, I love your scenario - very fun. I think I've heard Mike Cohn actually call them "anti-user stories" in a talk.
Frankly though, I don't think it matters what you call them because they're a very short-term device. I wouldn't bother actually recording these anywhere because as soon as they're shared, they should result in real user stories that ...
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 ...
7
there are no stakeholders
If there were no stakeholders, the projects wouldn't have existed or had money in the first place. Chances are, they are not properly identified, and this is where you have to start.
It's not like the whole team should go search for random stakeholders. You can have a single person doing that, and, unsurprisingly, it better be a ...
7
Stakeholder management 101: define the rules of engagement, define the two-way communication requirements, point out and resolve the inconsistencies in the stakeholder requirements--such as what you pointed out here--and whatever else you need such that you get what you need from the CEO and he gets what he needs from you.
Schedule a meeting or two and ...
7
I am drawing assumptions on your PO's agenda, based on my experience of other PO meetings, and discussing a stakeholder's objections on spend would not be consistent with that agenda. The PO, or you, or another leader of the team, should acknowledge the issue, validate the issue, and then table it with a promise of an immediate meeting to discuss further. ...
7
TL;DR
I was thinking at the back of my mind to either:
defend the PO and budget
defend the team, since they were kept busy delivering items from the backlog
Bring focus to the meeting by telling POs to keep focus on delivering high value items in the following sprints
The correct answer is "none of the above." Your goal as Scrum Master isn'...
6
Represent the Stakeholders to the Agile Team
The primary role of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team:
Provides timely information and decisions on requirements and priority
Is an active participant in customer testing
Facilitates requirements gathering
Represent the Agile Team to the ...
6
The following is pulled from a few different sources (including my own experience as a solo freelancer with multiple clients); however, you mentioned Agile and Scrum - so my terminology will be similar.
Shorter development efforts, with extended silence:
What I found worked for me was to have, essentially, a one week sprint. On Monday, you meet the ...
6
Project Objectives are typically higher level than individual Stakeholder Requirements. They usually come first, created up-front in the Project Initiation phase before you've delved in to individual Stakeholder Requirements.
Stakeholder Requirements are lower level and more specific that Project Objectives. They'll carefully define the needs of the various ...
5
TL;DR
Your process may be missing some intermediate queues in your work-flow, making estimates harder than they need to be. You may also need to work more closely with your stakeholders to decompose epics in order to provide meaningful estimates. And finally, you may need to provide your team and organization with more education about how estimates are ...
5
Despite the fact that I agree with David that design by committee is sarcasm [and a real phenomenon, I agree with Michael Hogan too :-)], question is about examples (not about "design by committee" term).
So, take a look at this article.
There is a list of projects designed by committee in the "Case Studies" part:
Design by Committee: The U.N. ...
5
Stakeholders are anyone who has a stake, role, share, etc. in the project. I am not sure the schools are stakeholders at all because based on the limited description of the application, you are targeting students, not schools. If you plan to partner with schools to help market or get proprietary university data, then they can become a stakeholder; however, ...
5
As a Scrum Master I encourage team members to talk with the stakeholders. But I suggest they either do it in the presence of the Product Owner or brief the Product Owner as soon as possible after the conversation has finished.
The Product Owner sees the big picture. What sounds like a perfectly reasonable request to a developer might actually be a bad idea ...
5
Excellent question:
To answer the question directly, yes, the developers can and should talk with the customer when possible. As you've pointed out though, the logistics of this can be difficult.
Something that is rising in use, that directly addresses this, is the Product Owner Team (also known as the agile business team and the agile customer team).
...
5
From Agile Manifesto - "Responding to change" over sticking to a plan.
It is a good practice to respond to a change so that your product/project evolve in right direction. It will lead to client's satisfaction.
But there are some precautions you can take.
1. Please start writing the requirements in the form of Stories (As a user<>.. etc) and also with ...
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
There is a difference between an estimate and planning value. An estimate is a probabilistic range and should include variables such as less qualified resources doing the work plus about 1,000 other aleatory and epistemic variables. Therefore, the proper estimate should have been 70 to 200+ hours. In this range, you need to chose the planning value, say ...
4
As an Information Security Architect, I am with you on the idea of anti-story, and I would counter Daniel and request that they do become permanent record.
In Archimate, you can model risk as events, then design security measures to counter them. The same approach could work well for user stories. This is similar to Daniels last approach, but retains the ...
4
Honestly, this sounds like the Product Owner is a typical type-A personality that has learned to get better results from relentlessly pushing his teams to always do more and better. (Think Elon Musk.) There's nothing inherently wrong with this because it's his style. As the Project Manager, it's your job to bridge communications between the Product Owner and ...
4
Summary
You must leverage your framework more effectively. This includes pulling your stakeholders into Backlog Refinement and explaining the iterative/incremental nature of the project's delivery framework.
You also need to increase the level of collaboration with the CEO. Being dismissive or using emotion-laden statements like "he moans all the time" are ...
4
I'm a big fan of a continuous feedback loop rather than making it stick to a schedule.
My suggestion would be to:
Deploy frequently to your staging environment (whenever you have a stable build).
Inform your stakeholders of anything new and significant in the staging environment (perhaps with a newsletter or updated wiki page).
Accept feedback at any time (...
4
It seems a little surprising that one of the answers hasn't covered this, but: do you hold a review meeting at the end of the iteration?
Scrum and XP both include this meeting to address the challenge you raise. This meeting gets all of the stakeholders there using your app and giving feedback at one time and place before your next sprint. It also gives the ...
Only top voted, non community-wiki answers of a minimum length are eligible
