In Scrum, Who are the Key Stakeholders that Should be Attending Every Sprint Review?

The Scrum Guide requires that the Product Owner ensure that “key stakeholders” attend the Scrum Sprint Review, but who are these “key stakeholders”?

According to the Scrum Glossary, a stakeholder is “a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.”

Typically, they fall into one of three broad categories:

  • The Users – The human people who actually use^1 the software product under development, to help them or the organization make more money or save money.

    • This could include a human compliance officer within a company, who is responsible for making sure that the software systems comply with government or financial regulations.
    • This could include the humans who support the operations or production support for the product.
    • Upstream/Downstream systems could also be considered “users” so long as we don’t forget the human end users of those systems. Don’t forget the humans!
      • Downstream reports are a good example of a downstream system” where you should definitely not forget the “human end user”, but there are other examples.
  • The External Customers (doesn’t exist for internal products — see below) – The people responsible for paying to use the software product.

    • Only applies to externally sold or externally developed products
      • By external here, we mean, outside the company doing the development.
    • In a “software development for hire” arrangement(externally developed product), the client who engages the team would be the External Customer.
    • Sometimes the External Customers and Users are the same people — take TurboTax as an example, or a software product whose human users also make the decision to purchase said product.
  • The Internal Customers – The people responsible for making the funding decisions for the software product development effort.

    • This is usually someone in Product Management(usually for external products) or someone in management in the Line of Business(usually for internal products) that is supported by the software product.
    • It could also be the CEO or CIO or similar roles at times.

There are probably exceptions to the above three broad categories. Also, don’t assume that the Product Owner can only consider “key stakeholders” as sources for requirements or good ideas. The Product Owner can work with anyone any time (possibly during Product Backlog Refinement and other activities) who can supply good ideas to capture more value for the product. Our discussion of key stakeholders here is just to understand how the “stakeholder” role in the Scrum Guide can be interpreted.

The key stakeholders are the people that receive a direct financial^2 benefit(helps them or the organization make more money or save money) from using the software.

One could also think of the management of the development organization as a stakeholder who should attend Sprint Reviews, certainly in replacement of any and all status reports and any and all other progress reporting for the Scrum Teams. If any Dev management asks for these things, the answer should almost always be something like “In Scrum, that information is communicated in Sprint Reviews, so let me get you on the invite list for that.” For Scrum “key stakeholder” purposes though, I’m not sure I’d call Dev management “key stakeholders.” or think of them as being “required” to be present(unless of course, they request status/progress reports).

In some cases, you’ll have so many “users” that it is not possible to have all of them in your Sprint Reviews. In those cases, try to get a representative sample of human users into your Sprint reviews(some companies pay for this kind of feedback from human users), and also utilize other feedback gathering mechanisms. (See “One PO Can Do it All!” in this product ownership article.)

Parting Words

I’m sure that there are exceptions to the above three broad categories, so feel free to let me know if you can think of some noteworthy ones, or maybe see if you can effectively place them under one of the three broad categories above. Talk to the Product Owner and make sure that they are ensuring that key stakeholders are are attending your Sprint Reviews, as their input is absolutely vital to the success of the product.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

———-

Notes:

^1 Rare exception — note that sometimes a software development team acts as a “Production Support Engineer” user, but this should only apply to features actually in the product(support logging might be a good example) that help with production support. However, the modeling of a human user who is on the software development team should not become a guise for so-called “technical stories” or technical practices. That’s not a real “user”.

^2 Rare exception — If the organization developing the software is a non profit, government entity, or charity, then instead of “financial benefit” or “money”, we might say “the societal benefit” instead.

Helping Scrum Masters Improve: What would be on your Scrum Master Canvas?

I see a lot of Scrum Masters who focus on the wrong things. I was having some conversations with some Scrum trainers recently, and the conversation inspired an idea in me: The Scrum Master Canvas.

The Scrum Master Canvas

The Scrum Master Canvas, similar to the Business Model Canvas that we teach in our Product Owner courses, focuses on the things that a Scrum Master should be thinking about, in order to help her team get better at delivering more value, sooner.

So, I’ve started with some initial section ideas that might be useful to have on such a canvas:

  • “Long term Impediments”
  • “Short term Impediments”
  • Service to the Organization
    • “What are my next steps in coaching the organization to get more benefits from Scrum?”
    • “Which audiences require the different Coaching Stances?” (A table with “audience” and “coaching stance” column headers)
    • “What is on the radar of the wider Scrum Master Community of Practice?”
    • “Organizations (and sometimes me!) tend to incorrectly assign duties to the Scrum Master. What are my next steps in re-focusing those duties to where they really should be directed in Scrum?”
  • Service to the Development Team
    • “What are my next steps in helping the Dev Team become more Self Organizing so I can ‘Let the Team Decide’?”
    • “What is on my Dev Team’s Improvement Backlog right now?”
    • “What are my Dev Team’s next steps for achieving a higher degree of technical excellence?” (A table with “Next Steps” and “How can I support that?” as column headers)
    • “What things should I NOT do, so that the Scrum Team can become more Self Organizing?”
    • “What are my next steps in teaching/coaching the Dev Team to understand and enact Scrum?”
  • Service to the Product Owner
  • Service to myself, the Scrum Master
    • “In order to help my organization grow its’ Agility, what are my next steps for me learning and self improvement?”
    • “Am I working at a sustainable pace? Do I need to coach others on what that means?”
    • “What things should I NOT do, so that the Scrum Team can become more Self Organizing” (repeated for emphasis!)
    • “What else do I need to focus on, that’s not covered in a different section?”

The Scrum Master would initially create this canvas, put it on a rather large piece of paper (Information Radiator!), and likely hang it in their office in a place that is highly visible to those who walk by. In this way, in addition to focusing the Scrum Master on their role, it would also educate others in the organization on what a Scrum Master should focus on. Often times the wider organization also encourages the Scrum Master to focus on the wrong things. Maybe having this canvas would help them change their expectations of the Scrum Master, too. Anyway, you get the idea.

The Scrum Master would also probably want to schedule a calendar reminder, say every Sprint or so, to review their Canvas, edit it, and make sure they are staying on track. Then, maybe another set of calendar reminders every month or every quarter, to create a fresh copy of the canvas.

For a high quality class that focuses exclusively on the Scrum Master role, see our Professional Scrum Master class and contact us if you’re interested in one.

So, what would be on your Scrum Master Canvas?

Breaking News!! Jeff Sutherland’s Scrum Inc introduces “Scrum At Scale” — see it at Agile 2014 session

I was lucky enough to get a preview of the “Scrum At Scale” approach from Scrum Inc a few days ago. In short, it’s a model for conversations around how to think about scaling Scrum in the enterprise. The model is modular, and it is very clear that this approach is more lightweight and flexible than other Agile scaling approaches that get a lot of attention. Alex Brown of Scrum Inc, the Product Owner for the model, as well as Jeff Sutherland, are very adamant that this this not some cookie cutter recipe or methodology to scale Scrum. It’s different than other approaches, in that it’s a model for conversations around inspecting and adapting toward success with Scrum at Scale.

I’m told that the slides for the presentation at the link above will be posted there within the next couple of days, and possibly sooner. The slides will add a lot of detail that the main graphic doesn’t give. I will also add that there is some nuance and detail not included in the slides either. As such, I recommend try to attend one of their live or recorded video presentations to get some richer nuance…. or….

They are also presenting on this topic at Agile 2014 next week. If you’re going to be at Agile 2014, I highly recommend you put their session on your “must see” list.

The model gives a “big picture” view of Scrum in the enterprise, but it also dovetails nicely with the many years of work that Jeff Sutherland and others have put into their Scrum Patterns efforts. As you may know, I’m also a fan of this Scrum patterns concept, and you can see an example of that work on my website — Daily Scrum Patterns.

It’s worth mentioning that I have no business relationship whatsoever with Scrum Inc, so I’m not in any way incentivized to advocate for their approach.  I’m only endorsing it because I believe in the approach and in it’s future.

I suspect that this work will be a game changer in the Scrum scaling space, which doesn’t surprise me, really. It *is,* after all, coming from a company run by the co-creator of Scrum! Nice work Alex Brown, Jeff Sutherland, and Scrum Inc!

Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives?

For much better alternatives to SAFe(tm), see this page.

All my personal/professional opinion.

I’m not a big fan of SAFe(tm). I haven’t yet had time to sit down and detail all of the problems I have with it, but I’ll hit a couple.

1. It’s not Agile at all. It’s a sales strategy.

My biggest problem with it is that it condones old, out of date, and dysfunctional practices that don’t enhance Agility. It is essentially a hybrid approach of Waterfall and Agile, along with a lot of baggage from RUP. This probably shouldn’t surprise anyone since the creator, Dean Leffingwell, was a big salesman/evangelist for RUP. The biggest baggage from RUP is the complexity of a zillion different roles and the fact that SAFe is a “slice and dice” methodology. It’s not a framework. I think the “slice and dice” thing is really just a slick sales strategy. It allows those selling SAFe to immediately disown any practice of SAFe that a potential client complains isn’t Agile or won’t work. It also means that any tiny subset of SAFe is still considered to be SAFe. As such, I just consider this a sales strategy to sell more billable hours. This strategy was also used in RUP, and yet… over the years… which has prospered more? RUP or Scrum? Scrum is a framework, so there is no slice and dicing of the framework itself.

2. It misleads people into thinking that it uses Scrum at the team level.

It claims to use Scrum at the team level, but then completely sells out Scrum in so many ways. It sells out the Product Owner role by giving control to all manner of people over the Product Backlog contents, something Scrum expressly forbids. It sells out the Scrum Master role by suggesting it’s a 25% time commitment. Then, it completely sells out the Development Team by creating Ivory Tower architects.

3. To date, no Agile Manifesto author has endorsed it. That should tell you something right there.

This one is self explanatory. :-)

The reasons I don’t like it are covered in way more detail in these reviews of SAFe by other people who are sharp enough to tell the differences between SAFe and other approaches, as well as the history behind similar practices and approaches

For much better alternatives to SAFe(tm), see this page.

Great Article from Scrum Co-Creator Ken Schwaber on “Agile Value”

Ken Schwaber’s written a great article on Agile Value .  He talks about how value can be defined in Agile, and the article also covers the difference between traditional project management metrics and Agile project measurements.

On a related note, see Common Project Management Metrics Doom IT Departments to Failure

Scrum and Agile Adoption: Backsliding into Waterfall Habits

It’s very common, when an organization is in the Shu level of learning Agile or Scrum, for it to fall into old, bad, waterfall habits.  Today I’d like to talk about two bad waterfall habits:  tracking so called ‘individual velocity,’ and tracking actual effort expended on a task or story.

First, tracking some sort of metric like “individual velocity” is probably an excellent way to completely sabotage your project/product and it’s also a great way to kill your Agile adoption.  A key concept in the Agile Manifesto principles, as well as in Scrum, is team work and “self-organizing” teams.  Self organization is generally the ability for a team to create and execute their own plan of work(Sprint Backlog), as well as decide “How” to do their work.  Whenever there is a single entity (individual on or off the team, department, etc) who strongly influences or makes unilateral decisions for how a team works, there is, by definition, no self organization.  Tracking individual velocity, or any similar “individual incentive” (this can include raises, performance reviews, awards, etc) does not encourage team work at all.  In his book, Agile Estimating and Planning, Mike Cohn says it this way:

“If I am forced to choose between finishing a story on my own and helping someone else, what incentive does measuring individual velocity give me?  Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do. Team velocity matters; individual velocity doesn’t. It’s not even a metric of passing interest.”

Tracking actual effort expended is another really bad waterfall habit.  Tracking estimates and actuals is just another example of where Common Project Management Metrics Doom IT Departments to Failure.  Mike Cohn, an Agile and Scrum thought leader, and a former project manager himself, says this about tracking estimates and actuals:

“On a project, it is far more useful to know how much remains to be done rather than how much has been done. Further, tracking effort expended and comparing it with estimated effort can lead to ‘evaluation apprehension’ (Sanders 1984). When estimators are apprehensive about providing an estimate, the familiar ‘fight or flight’ instinct kicks in, and estimators rely more on instinct than on analytical thought (Jørgensen 2004).

Tracking effort expended in an effort to improve estimate accuracy is a very fine line. It can work (Lederer and Prasad 1998; Weinberg and Schulman 1974). However, the project manager or whoever is doing the tracking must be very careful to avoid putting significant evaluation pressure on the estimators, as doing so could result in estimates that are worse rather than better.

Additionally, keep in mind that variability is a part of every estimate. No matter how much effort is put into improving estimates, a team will never be able to estimate perfectly. Evidence of this is no further away than your morning commute to work. There is an inherent amount of variability in your commute regardless of how you travel, how far you must go, and where you live. If you drive to work, no amount of driving skill will eliminate this variability.”

In a later post on the ScrumDevelopment Yahoo Group, Mike summarizes it this way:

” I’d say you shouldn’t do it because it doesn’t add value commensurate with its cost. Don’t argue with your bosses that it ‘adds no value’ because
comparing what you originally thought a task would take with what it did take can help make you a better estimator.

But, it can be time-consuming to track actuals, especially for a full team where some on the team are probably already decent estimators.

Because Scrum already has solid mechanisms for monitoring whether all the work gets done in a sprint (high team commitment, daily burndown charts, daily scrum, and so on), Scrum does not have the same reliance on early and accurating estimating that a predictive or waterfall approach does.

So–the cost to gather actuals is the same in Scrum or waterfall. The benefit in Scrum is greatly reduced.”

So, be very careful when backsliding into old waterfall habits.  It usually happens in small doses, which is why many Shu level adoptions don’t notice it, especially if they don’t have a skilled Scrum Coach or highly experienced Scrum Master around.  The other thing to keep in mind is that, even if you do have someone skilled around, this old adage still applies:  “You can lead a horse to water, but you can’t make ’em drink.”

What kind of backsliding into old waterfall habits have you seen?  What do you suggest be done about them?  Sound off in the comments below!

The Summer of Scrum: Ken Schwaber Announces New 2013 Scrum Guide

Ken Schwaber announced today that a new Scrum Guide is coming in the next couple of months.  In my position as a Professional Scrum Trainer certified through Ken’s Scrum.org, I was aware of this earlier this year and I have to say… the Scrum nerd in me is excited!  It’s so great to see that Scrum is evolving, because this is one reason many of the past methodologies and frameworks died out.  It’s also very much in line with the “inspect and adapt” nature of Scrum, so it’s wonderful to see Scrum’s founders and shepherds leading by example.

I also want to drop another hint.  There are some other interesting things happening in the Scrum world this summer that I cannot yet talk about.  Subscribe to my blog to stay tuned!

Scrum On!

Other posts you might be interested in:

Follow

Get every new post delivered to your Inbox.

Join 369 other followers

%d bloggers like this: