Please specify if you mean specifically "stakeholder" as defined by scrum or if you are just using the term in a general sense? The answer is completely different based on this context.
–
Jimmy HoffaNov 15 '12 at 16:40

The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the system and everyone else in an organisation that may be affected by its installation. Other system stakeholders may be engineers who are developing or maintaining related systems, business managers, domain experts, and trade union representatives.

My definition of a project stakeholder is anyone who is a direct user,
indirect user, manager of users, senior manager, operations staff
member, the "gold owner" who funds the project, support (help desk)
staff member, auditors, your program/portfolio manager, developers
working on other systems that integrate or interact with the one under
development, or maintenance professionals potentially affected by the
development and/or deployment of a software project.

...

In this definition I have chosen to exclude the developers who are
working on the project. This may seem strange at first because
developers clearly have an important stake in the projects that they
work on. Yes, developers are definitely project stakeholders. Why do
I continue to distinguish between developers and project stakeholders?
Because I want convenient terms to distinguish them, I really don’t
like “developer stakeholder” and “non-developer stakeholder”, and
because they have different roles to play on a project.

In practice, I've typically seen stakeholders broken down into groups, and one group contains the people building the system. It is important to recognize that, when building a system, the developers do have needs and concerns that need to be balanced with the needs of everyone else. However, these need to be prioritized and taken into consideration with every other need.

Usually no, but there can be exceptions. "Eating your own dog food" comes to mind as the main exception as in this case the developers may be using what they build directly and thus they are stakeholders to some extent. However, I'd question if this was more than a few percent of developers overall though.

...definition of a project stakeholder
is anyone who is a direct user,
indirect user, manager of users,
senior manager, operations staff
member, the "gold owner" who funds the
project, support (help desk) staff
member, auditors, your
program/portfolio manager, developers
working on other systems that
integrate or interact with the one
under development, or maintenance
professionals potentially affected by
the development and/or deployment of a
software project...

Stakeholders are individuals external to the current product development team in one form or another. If you are on team X and another developer is on team Y and you are working on differing products which interact with each other at a later point in time then you become a stakeholder in each others product.

@Jim I don't agree with the fact that developers within the direct team are stakeholders. The whole idea is that stakeholders prioritize the backlog, stakeholders appear at the sprint review meeting, stakeholders make decisions about the project outside of the coding approach, etc... The developers within the direct team working on the project by the above mentioned items are not stakeholders. Are they part of the overall team be it Scrum or some other methodology? Yes; but stakeholders they are not. The pig and chicken fable is about commitment to the project...not being a stakeholder.
–
Aaron McIverJan 13 '11 at 17:54

1

I'm just pointing out that you're citing someone to support your position who would not agree with your position. For the purposes of that discussion, he's using "Stakeholders" in the narrow sense, but also says that he considers the concept to normally encompass the developers as well. Why cite someone who disagrees with you to make a point? You're better off stating your point of view without reference and letting it stand on merit of your own arguments.
–
MIAJan 13 '11 at 18:16

1

@Jim I quoted what was relevant and gave credit to the source. Surely you wouldn't expect me to cite a passage in a novel yet expect that everything within the novel was relevant to my citing? Same idea.
–
Aaron McIverJan 13 '11 at 18:26

1

Alright then, I guess I can buy that. Sometimes folks cite others without reading the whole thing. I made a whitespace edit so I could pull the downvote off.
–
MIAJan 13 '11 at 20:38

Yes - for a system that will live on and be maintained. Developers are likely to work with the code to fix bugs and introduce new features long after the initial team closed the project. An important requirement for long lived systems are maintainability and who should put their stakes in this if not developers?

After a bit of googling, I must say that this is an unanswerable question. There is no one definition of a stakeholder and different sources use it differently.

As the Scott Ambler reference by Aaron points out, more than one methodology avoids the term altogether. Others try to break it down into different categories of stakeholders. The result is that while there's a general meaning that stakeholder is "someone with interest", the precise meaning is lost.

What that interest is comes down to one of two meanings in my mind:

Those who expect to derive primary value from the application

or

Those who will invest in the outcome of the project.

The sponsorship body fits either definition. How end users fit into the sponsorship body is another topic entirely. For now, lets assume they do fit in because I'm not willing to split hairs on it.
Anyone on the project team fits the second meaning as well.

In the end what matters is that value is derived from our applications and we understand that the sponsors get the final word.

My general feeling is that people who want to lump in developers into the "Stakeholders" group largely care because they have seen situations where developers are treated as cogs in a machine and often treated poorly as a result. Feedback on requirements is not allowed, significant unpaid overtime is mandatory, etc. Because you're giving up time and sanity above what should be expected, there are people inclined to see that as an investment. Investment = stake so in their minds the development team are stakeholders.

As a result, I'm not a fan of the term. "Sponsors" is clear. "Stakeholders" is not.

What? So you're saying that if the programmer creates crappy software and as a result the company that sells the software cannot survive, that the programmer would not care?
–
Klaus Byskov HoffmannJan 13 '11 at 15:21

@Klaus - I think it assumes a basic level of professionalism, that is he won't produce crappy software.
–
Jon HopkinsJan 13 '11 at 15:43

5

If I lose my job as a result of the project failing, I'm guessing I'm affected. If I'm the one working 60+ a week, I'm affected. Please clarify your definition of affected.
–
MIAJan 13 '11 at 17:47

1

Developers are among those most affected by the success or failure of the project. Personal stress, corporate status, current and future employment -- all these and more are affected by the progress and outcome of the project.
–
comingstormJan 27 '12 at 23:08

They may be. If their postion after the product is finished will be different than before, they are a stakeholder. For instance, if a developer is paid a salary to develop software for a company, chances are he is not a stakeholder because nothing will change afer the product is delivered. However, if he is a partner in a startup, where his financial position depends on the product being successful, I would argue that he is a stakeholder.

Another example would be the (admittedly rare) case of a developer making software that he will use. In that case, he definately is a stakeholder because he has a vested interest in having that software work correctly.

Developers are indeed stakeholders (affected by what is produced): both those who initially develop a system, and those who maintain it. The former tend to be interested in new technologies and increasing their skill base, whereas the latter want to be able to keep up with the usually large number of systems they have to maintain.

However, 'legitimate' stakeholders is another question. When balancing requirements, all stakeholders are certainly not going to find their concerns addressed to their satisfaction. Is your company worried about losing top developers? Bump up developer concerns. If not, developers tend to end up fairly low on the totem pole. Unfortunately, this can have the effect of ignoring maintainability as well, building up technical debt like there's no tomorrow.

A stake holder includes anyone who has a stake or interest in what the system does because then they will have some requirements to say what it should do. Therefore I wouldn't include developers in a project where the code is simply pushed out the door and forgotten but would include them if they are supporting the project or extending it as it is then the developers require the system to be maintainable/extendable.