The New New Product Owner: The Product Marketplace Expert

In my previous post, I discussed the 7 focus areas for the New New Product Owner, as well as the “Product Value Maximizer” focus area.  In this post, we explore the “Product Marketplace Expert” focus area.

The New New Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster. Note here that the New New Product Owner may or may not be the one doing the legwork of gathering the marketplace data(they might delegate), but they should certainly be aware of the market research.  Often times the New New Product Owner will delegate to others or to automation to aid them in obtaining the market data.
Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to gather the marketplace data.

With IT software, the market data will often include how the LOB(Line of Business) uses the software, as well as understanding the business function that the LOB executes on.  Heavy interaction with those in the LOB will usually yield this data, or again, the New New Product Owner might delegate or rely on someone in the LOB to supply her with that data.  A good starting point for gathering this data is understanding who your key stakeholders are.

Additionally, the New New Product Owner should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

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.

The New New Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Management, Product Backlog Refinement, and in Sprint Reviews.

Knowing the market for your product can help you fulfill another key focus area, being The Product Visionary.

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.

Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactly repeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Bottom Line

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Related Articles

• The Tao of Scrum – Transparency

• Scrum For Lay People

• One way to handle Bugs and Production Support in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.   Contact us for more info

Towards a Catalog of Scrum Patterns

I’ve been thinking a lot lately about Scrum patterns.  To that end, I’ve drafted a conceptual model, which is depicted in the below image.  (You may want to click the image twice to see a bigger view of it)

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.”  In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required.  In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team.  So, this is what inspired me to use the term “Scrum Technique Pattern.”  A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide.  Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework.  Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide.  These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context.  For instance, we might start out with a Scrum Starter Kit that includes things like:

• Holding a Release Planning meeting every 2-3 months (OSP)
• 2 Week Sprints (STP)
• Using Story Points to estimate Product Backlog Items(STP)
• Using Ideal Hours to estimate Sprint Backlog plan items(STP)
• Doing a typical burndown chart to sum the remaining work for the sprint(STP)
• Representing Undone Work(OSP)
• Doing the typical “round robin” style of the Daily Scrum(STP)
• Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum.  Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns?  Where do they come from?

In a word, anywhere.  I’ve seen dozens of them on the internet and in books.  I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due).  I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum.  Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

---

Scrum

1. The Scrum Guide (Must read for all)
   • http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf
2. Deemer, et al. “The Scrum Primer”
   • http://www.scrumprimer.com/
3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
   • http://www.amazon.com/Agile-Product-Management-Scrum-Addison-Wesley/dp/0321605780
5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
   • http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
   • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
7. Derby/Larsen’s _Agile Retrospectives_
   • http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

---

XP (Extreme Programming)

1. Jeffries’ “What is Extreme Programming?”
   • http://xprogramming.com/book/whatisxp/
2. Jeffries’ _Extreme Programming Installed_
   • http://www.amazon.com/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426
3. Koskela’s _Test Driven…_
   • http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
4. Martin’s _Clean Code_
   • http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
5. Feathers’ _Working Effectively With Legacy Code_
   • http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
6. “The Rules of Extreme Programming”
   • http://www.extremeprogramming.org/rules.html
7. Wiki entry on XP Practices
   • http://en.wikipedia.org/wiki/Extreme_programming_practices

---

Agile/XP Testing

1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
   • http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/
2. Cripin’s “Using the Agile Testing Quadrants”
   • http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
3. Crispin/Gregory’s _Agile Testing_
   • http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
4. Crispin/House’s _Testing Extreme Programming_
   • http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551
5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
   • http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
6. Osherove’s _The Art of Unit Testing_
   • http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274

---

User Stories (which originated in XP)

1. My “User Story Basics” article and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/User+Story+Basics
2. Cohn’s _User Stories Applied_
   • http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Lawrence’s “Patterns for Splitting User Stories”
   • http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

---

Special Agile Topics (if applicable)

1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
   • http://www.goodagile.com/distributedscrumprimer/
2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/The+role+of+Managers+in+Scrum
3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
   • http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

Best Practice: Look to the Scrum Guide *First*

Short Story:

When teams struggle with Scrum, it is my strong opinion that they should look *first* to the Scrum Guide for guidance.
(Or *look back* to the Scrum Guide, if they are an experienced team)

Long story:

A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look *first* to the Scrum Guide, and secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don’t contradict the Scrum Guide, then it’s probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.

I have observed the following Anti-Patterns with respect to Scrum implementation.

Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that “something, ” often times because the “something” is not really Scrum at all, but some practice that someone inaccurately said was Scrum.
3. Rinse and Repeat until either:
a) “Scrum” is a dirty word in your organization, or b) your organization settles for mediocrity, or c) you decide to move on to some other process, or d) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.

Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.

Faux Scrum: Pretend you’re doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. “Hey look, Mom! We’re Agile!”
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the “Methodology Facade Pattern”)

Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above

The Power of Positive Thinking
I know what you’re thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I’m generally a very positive person. I’m even hilarious at times, but that’s hard to convey in prose about intellectual topics. I think, though, that they would also tell you I’m a very detailed person, and that I’m honest and direct about serious subjects.

So, rather than call everyone “Chickens” and “Scrumbuts” and “Faux Scrumites”, what I do instead is I advocate a positive strategy.
That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.

If you look at my blog and web site, I generally give positive advice, but I also don’t shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.

Sometimes, to convince people to get back to basics, I have to point out where they’ve deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That’s part of being a Scrum Coach and change agent, and comes with a certain amount of resistance. I’m ok with that. The reason I’m ok with that resistance is that I do it because I passionately and honestly believe it’s the right thing to do.

Tips for a Good Sprint Review

Sprint Review Tips

These tips are not a part of Scrum according to the Scrum Guide. They are my own personal tips based on my Scrum Coaching experiences. I do believe these tips are consistent with the Scrum Guide.

• First, foremost, and most importantly, know what a Sprint Review is supposed to be. Read the Scrum Guide, it’s only like 20 pages. Specifically, read the section on the Sprint Review and make sure your team is in alignment with the Sprint Review as it is described in the guide.
• It is a worst practice to use the Sprint Review as a signoff or user acceptance meeting.
• Make the demo be an informal one, maybe even done on a developer’s machine.
• Spend no more than 1 person hour preparing for the demo.
• Have your Product Owner play the “lead emcee” role in the Sprint Review.
• Have the ScrumMaster be a silent observer in the Sprint Review. Ok, maybe not a silent observer, but at least a role where they only get involved in the review if it’s absolutely necessary to clarify Scrum roles, rules, or principles.
• Treat all feedback as welcome feedback.
• Treat the Sprint Review as if you were doing a focus group on your just completed features. Be curious about any hint of feedback, and ask for suggestions from everyone (including developers) on how to gain more value from the current and future features.
• Never say “no” outright to a new feature or enhancement request. Always put it on the backlog. It may go way down in priority on the backlog, but put it there. You might word the backlog item slightly differently than the suggester did, but put it there. Try to word it as a request for functionality or request to solve a problem (“the what”)rather than a “do it this way” command(“the how”).
• Any feedback that results in changes to be implemented is a new Product Backlog Item.

 

Related articles:

• Tips for a Good Sprint Review
• Worst Practice – The Sprint Review as a Signoff Meeting

Executive Summary: The Sprint Review

Summarized directly from the Scrum Guide.

Goals

• Informal meeting
• Present work just completed(demo)
• Collaborate on work just completed in the current Sprint
• Use work completed and current state of Product Backlog to collaborate about what to do in the next Sprint

Minimal Requirements of the Sprint Review

• Time-boxed to 1 hour per per week of Sprint length
  • (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)
• Attendees: Entire Scrum Team + Stakeholders
• Agenda
  • Product Owner identifies what has been done and what has not been done
  • Development Team:
    • Talks about the Sprint
      • what went well
      • problems that arose
      • how it solved those problems
    • Demonstrates completed work/Product Backlog Items
    • Answers any questions
  • Product Owner:
    • discusses current snapshot of Product Backlog
    • projects likely completion dates with various completion rate(or velocity) assumptions
  • All attendees then discuss previous agenda items and how they affect what to do next
    • Provides vital input into the impending Sprint Planning Meeting

Related articles:

• Tips for a Good Sprint Review
• Worst Practice – The Sprint Review as a Signoff Meeting

Worst Practice: The Sprint Review as a Signoff Meeting

Summary

One of the “worst practices” I’ve discovered several times when coaching Scrum teams is when a team uses their Sprint Review as a “signoff” meeting, with either the Product Owner or other stakeholders acting as approvers. Getting feedback at a Sprint Review is great, but treating the Sprint Review (some call it a “Demo”, a mistake in my opinion) as some sort of acceptance meeting causes all kinds of problems. In this article, I look deeper at this worst practice from the following angles:

• Possible Symptoms
• Possible Causes
• Possible Consequences
• Possible Solutions

Link to full article

I encourage you to comment on the full article here on the blog, as every comment posted helps me and others to improve their knowledge of Scrum.