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.

Release Cadence Report: Agilists and Software Developers, Take 10 Minutes to Help the Software Community Get Better

The blog post I’m writing to you today is to encourage you to take 10 minutes of your time to fill out the “Release Cadence Report” created by Ryan Cromwell, an Agile community leader that I respect very much.  I get emails often from people wanting me to fill out Agile surveys, and I usually just don’t have the time.

This survey is different, and I took the time(about 10 minutes) to fill it out.  I suggest you do as well.

.

In short, please take 10 minutes to take the survey, then pass along the link to fellow software professionals and Agile enthusiasts.  The survey will only be open for a limited time, so please just take the time and get ‘er done!  I’ll let Ryan take it from there.  See below.

——-
Charles Bradley

Professional Scrum Trainer, Scrum.org
Scrum Coach-in-Chief, ScrumCrazy.com

.

————————–

The current information and data available to organizations contemplating Scrum, Agile, Kanban, XP, etc. have grown very stale.  For the most part, the same practices, frameworks, methodologies and trends show up year after year with little exception.  The question is no longer if Agile is the place to be, but how to get there.  I think we are in need of an evolution in our discussion of Agile.

.

Today I opened the Release Cadence Report survey to move the needle towards what I hope is a more useful conversation than the state of Agile.  The report will be publish freely so that everyone can look at the relationship between Release Cadence and things like Market Capability, Employee Satisfaction, Patterns & Techniques used to achieve the cadence, Methodologies, and more.  With it, I hope that we can start talking about how companies have navigated their way to successful products as opposed to iterated their way towards challenged projects.

.

You can fill out the survey at:

https://www.surveymonkey.com/s/releasecadence?c=joljhy78.

.

Ryan Cromwell

————————–

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes 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.  Feb 28th in the Denver Tech Center.  More info and sign up here!

Best Practice – Minimize Manager input in Retrospectives

One of Scrum’s main tenants is about self organization. Self organization is difficult enough to achieve on its own, especially with a new Scrum team or a team who has members who are new to each other on it. In the context of this article, when I say “Manager”, I mean someone who has a large amount of input in determining the company advancement (performance reviews, raises, promotions, etc) of any individual on the Scrum Team. It could be someone a team member reports to, or it could even just be a supervisor or team lead. Sometimes a Manager plays a Scrum role like Product Owner or Scrum Master. I’m *especially* talking about those managers. Those managers should not attend the retro, or at the very worst case, should attend only a minor part of the retro(See “Strategies” below).

It should be obvious to Managers (though often it is not), that honest genuine feedback about how to work better as a team is very hard to get with a Manager in the room. Every time a person opens their mouth, they are taking a political risk if their manager is there, and that is not a safe environment for true collaboration and innovation. Managers, if you don’t believe me, try the strategies below for 3 sprints, and judge the results for yourself. You, as a manager, have every right to ask the team, one day after the retrospective is over, for their plan of action on improvements. I say one day after because I’d strongly prefer that you not come into the room where the retrospective is being held once it is over. Often times there are things on whiteboards that you may or may not understand, and again, that becomes unsafe.

Strategies

• Appoint a Facilitator
  • If a Manager does not fulfill a Scrum role, then the team should appoint a facilitator, preferably one totally independent of the team. Good candidates for this are Members of other teams with good facilitation skills and/or Scrum Masters from other teams. As a last resort, if that’s not possible, then appoint someone on the team who would be a good “neutral” facilitator. It’s ok if that team member also participates in the retro, but you can leave that decision up to them. Have the team prepare any specific feedback that they have that involves the Manager in their private retrospective, and present that feedback to the manager as a team. (Remember that they may have no specific feedback for the Manager, but often they will ask the Manager’s help in implementing Retrospective Action Items.)
• Part-Time Retrospecter
  • In the case where a Manager(or team lead) plays one of the Scrum roles (PO, SM, or developer), have the team, as part of their retro without the Manager, decide which topics will be discussed with the Manager. Any topic that is not chosen for discussion is not discussed with the Manager. In particular, any feedback the team has for the Manager in their Scrum role, have the team present that as a unified team rather than individuals. Also allow the Manager to raise their own independent topics, of course. If the Manager strays into one of the topics that the team has not chosen to discuss, then inform the manager of the outcome of the team discussion.

Excluding the Manager from the Retrospective is not an attempt to usurp the Manager’s authority or anything like that. It is to create the safety and experimentation that is required for great innovations to occur. The Manager still has a very important role to play — see The role of Managers in Scrum .

Related advice

• The role of Managers in Scrum
• Best Practice – Make Retro Action Items Highly Visible
• Best Practice – Review the Action Items from the Previous Retro in the Current Retro
• Best Practice – Change Up Your Retrospective Format

Related articles

• Best Practice – Look to the Scrum Guide *First*
• How I Classify Coaching Advice
• The Tao of Scrum – Transparency

Scrum Pattern – Plus Delta Hash(PDH) Retrospective

Summary

The PDH retrospective is a retrospective format that is very efficient and fairly simple. Teams quickly generate discussion topics(Transparency) by listing the things that went well(plusses) and the things that should change(deltas) to make the team better in the upcoming Sprint. The team then has a chance to quickly vote on the discussion topics to help prioritize and order the discussions. With the discussion agenda quickly set, the team then sets about discussing the most important topics(Inspection) and develops action items(Adaptation) that allow the team to improve its Scrum implementation.

Possible Contexts

• A team needs or wants a retrospective format that is very simple and/or efficient.
• A team that has a very limited amount of time to execute a retrospective.
  • I personally encourage teams to use the entire Scrum time-box so long as the team thinks it is continuing to have valuable discussions. Having *retrospectives that are too short* is an anti-pattern.
    • I encourage brand new Scrum Teams to use twice the time-box for the first 3 retrospectives so that the team achieves a culture of improvement and self organization. Don’t forget the definition of “time-box,” though — your meeting doesn’t *have* to take 3 hours — that’s just the max!
• A team that is of any size, but this pattern is very efficient for large teams.
• A team that prefers discussion and solution seeking over free form discussion.

Situations where this pattern might not be a good fit

• Teams that have done this retrospective format too many times and are bored with it.
  • Best Practice – Change Up Your Retrospective Format
• Teams that do not have the needed supplies or tools to execute this format.
• Teams where multiple members are working remotely (but see Variations section for a possible solution)

Steps

(This is probably obvious, but the number of votes and time-boxes can and should be adjusted to the team size, time allowed, etc)

1. Review the Previous Retro Action Items
   • Do this: Best Practice – Review the Action Items from the Previous Retro in the Current Retro
2. Generate Ideas about what went well, and what changes to make.Have each team member stand in front of a whiteboard (or large post it note) and list:
   • At least 2-3 Plusses
     • Things they liked about the current Sprint.
   • At least 2-3 Deltas
     • Things they would like to see change.
   • Time-box this to a fairly short period of time (5-15 minutes). Extend the time period in small increments if people need more time. During the time-box, remind peoiple that that they are encouraged to put more than the minimum — anything that’s on their mind. These items will become the discussion topics. If the need arises (and I’ve found that it usually doesn’t), discourage people from looking at others’ lists until they are done. As much as possible, we want independent topic generation.
3. Vote on the ideas to discuss and/or change.Hash Voting:
   • Now tell the team that they have 10 votes (you can adjust this of course, but it should be 5 at least) for Plusses and 10 votes for Deltas. Tell them to go around the room and put hash marks as their votes by topics they either a) want the team to discuss and/or b) that they agree with. They can place one vote on each topic or all of their votes on one topic. If they have questions about what something means, tell them to ask the author. Encourage them not to have the actual discussions yet, just to seek clarification of what the author meant by the topic. If they find similar topics and want to group them together as one topic, tell them to self organize to do that. Time-box this exercise to a fairly short period of time (5-10 minutes), and extend in very small increments if people need more time to vote or clarify/consoidate topics. Ideally, we really want to get people’s first instincts, so don’t allow too much time.
4. Count and rank the discussion topics. Count the votes and rank the topics(count and rank Plusses and Deltas separately) with the most votes(1, 2, 3, 4, 5, etc). This will become the “ordered discussion backlog”.
5. Discussion
   • Discuss Plusses
     • This usually takes very little time, but it is a chance to give each other attaboys and “I liked that too.” It also gives the team to reflect on the things that are going well, as a reminder to continue to do those things. You usually don’t need but about 5-10 minutes of discussion for those.
   • Discuss Deltas
     • Discuss the top ranked deltas, and have the facilitator monitor the discussions to make sure that they are fruitful. The facilitator should be sure to let the conversation go long enough to get to proposed action items and solutions. Each topic should end in an action item like the following:
       • Try something in the upcoming sprint.
         • Try a new approach
         • Change team working agreements
         • Change the definition of done
         • Some other thing to try
       • Take the discussion off-line into the upcoming sprint.
       • Agree to change nothing for one sprint and discuss it again at the next retrospective.
         • Another possible action item is, after discussing the topic, to keep things the way they are. I don’t like this kind of action item with important topics because it discourages trying new things. To me, a better solution is to try something for one Sprint and then retrospect again. A last ditch solution is to agree to keep things the way they are for one sprint and agree to definitely discuss it again in the next retro. If after two retros, there is no consensus on a suggested change, then it’s probably ok to go without an action item for that topic.
     • Each discussion should almost always end in an action item like the above.
6. Make the agreed upon action items highly visible on your Scrum Board.
   • Do this: Best Practice – Make Retro Action Items Highly Visible

Variations

• Remote Members strategy: For teams with remote members participating, consider a different setup where all members are on a conference call and simultaneously on a team wiki. Have each member create a wiki page for their suggested discussion topics. When voting, consider:
  • having the participants use their initials instead of hash marks to vote on the wiki page, OR
  • using the “secret ballot” strategy below.
• Secret Ballot strategy: If the vote placing itself gets a little cagey for the team (people waiting to put their votes until the last second, in order to more strongly influence the top topics), consider having the team jot down their votes on a piece of paper privately, and then have the facilitator randomly go around the room asking team members to voice their votes (“I had 3 hash marks on topic ABC, 2 for topic GHI, and one for XYZ”).

Supplies

• Preferably a room where the Scrum team can have discussions where no else can hear
• Several white boards and white board markers.
  • Large post it note sheets (~2′ x 3′) can be substituted if you don’t have enough whiteboard space.
• A facilitator to explain the rules and keep things moving.

Scrum Guide

This pattern implements the required elements of Sprint Retrospectives in the Scrum Guide. The required elements basically boil down to:

• Do a Retro every Sprint
• The entire Scrum Team participates
• Time-box it to 1.5 hours for a 2 week Sprint, 3 hours for a one month Sprint, etc
• Discuss what happened in the Sprint “with regards to people, relationships, process, and tools.”
• Discuss what should be changed in the next Sprint.
• Make a plan to implement the changes in the next Sprint.
  • Changes should be within the Scrum Framework. They should not be changes to the framework itself.

Origins

I’ve seen the “Plus Delta” analysis and “Dot Voting” (Hash Voting is a variation of Dot Voting) in several publications and web sites, but I don’t really know the origin of the techniques. This pattern is one I’ve developed over time in coaching Scrum Teams and it seems universally successful. Having said that, don’t forget the Best Practice – Change Up Your Retrospective Format. If anyone knows of the true origins of any technique described above, feel free to email me at the address on the home page and I’ll be happy to post it here.

Related advice

• Best Practice – Make Retro Action Items Highly Visible
• Best Practice – Review the Action Items from the Previous Retro in the Current Retro
• Best Practice – Change Up Your Retrospective Format

Related articles

• Best Practice – Look to the Scrum Guide *First*
• How I Classify Coaching Advice
• The Tao of Scrum – Transparency

I Mostly Hate Software for Managing Scrum Teams

Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

I hate the tools

Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Reason 2: They usually encourage bad habits, or at least enable bad habits. (Decreases Transparency & Productivity)

• Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.
• Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.
• Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.
• Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices.  I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts.  Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.

Best Practice – Make Retrospective Action Items Highly Visible

Here is how I define a Best Practice:

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
  • more details…

Many teams talk a good game on making changes to their development process, but fewer actually make those changes. Therefore, it is a Scrum Best Practice to make Retrospective action items highly visible to the team, usually on or very near the Scrum Board.

The visibility technique employed will be highly dependent on the team. Consider some of the following methods, or come up with your own!

• List them in big letters on a Scrum Board
• Create Sprint Backlog Tasks for action items and make sure they get to “done”.
• Do this: Best Practice – Review the Action Items from the Previous Retro in the Current Retro
• On certain days (Like Mon/Wed/Fri, Tue/Thurs, even, odd, every day, etc) in the Daily Scrum, have a team member pick a retro action item to talk about and have them talk for 30-60 seconds(time-box) about the action item. They can talk about the state of the item(announce completion!), why the item is important, give the person who came up with it or completed it praise, or even something like what life will be like once that action item is completed.
• On random days, offer a prize for anyone who can list a retrospective action item that is supposed to be completed in the current sprint. The prize can be very small or token, maybe as simple as candy or another desirable treat.

Best Practice – Review the Action Items from the Previous Retro in the Current Retro

Here is how I define a Best Practice:

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
  • more details…

Name of Pattern

• Retrospective Follow Up

Pattern Context

• Many teams discuss and say they want to make changes to their development process in a Scrum Retrospective, but far fewer actually make those changes.
• This pattern further refines the Sprint Retrospective practice of Scrum.
• The breadth of this pattern is any team that uses Scrum.

Problem

• Teams discuss process changes in their Sprint Retrospectives, but often don’t follow through with those changes.

Forces

• Positive Forces
  • Reviewing and/or discussing the status of the previous retrospective action items helps provide transparency about the adaptations being attempted and/or completed. This transparency and follow up makes it more likely that the adaptations will be completed.
  • Following through with changes to the development process is at the heart of what Scrum Retrospectives are for. Teams that follow through with these changes will improve their productivity in creating and delivering highly valuable products.
• Negative Forces
  • Taking the time to track and bring the action item statuses (or discuss the statuses) in the beginning of the current retrospective takes some time out of the current retrospective.
    • Teams that are already excellent at following up and completing the Retrospetive action items from previous retrospectives may not get a lot of value out of expending this time.
  • Teams that don’t implement their Retrospective action items will miss out on the possible improvements that could be made to the team.
  • At first blush, following up on a plan or action items may seem like common sense, but in practice, few Scrum Teams follow up well on their Retrospective action items.
  • Past product development practices often supplied some sort of “process improvement discussion” meeting, but didn’t put the emphasis on actually making process changes. Many newer Scrum teams fall back into this habit of complaining but not doing anything to make changes.

Solution

• The Scrum Team does a quick review of the status of the action items from the previous retrospective(s) at the beginning of the current retrospective.
  • As part of the review, it should be clear which items were completed and the status of any remaining open action items. The reason to review them at the beginning of the retro is so that any remaining open action items will be in the forefront of people’s thoughts.
  • The format and length of the review will be highly dependent on a team’s needs and how much a team already knows about the status of the previous retrospective action items. I suggest a length of between 2-15 minutes.
    • Quick Review
      • If everyone in the room knows exactly the status of each previous retro action item, then you can just make a statement like “These two items were completed, one was carried over, and one was not worked on at all.” (I generally recommend that teams focus on a small number of retro action items like 1-4).
    • Moderate Review
      • In a more moderate review, you can review each item and let team members say a few words about the state of each action item. Don’t forget the praise!
    • Graded Review
      • If you really want to inspect your improvement results, give each action item a letter grade (A, B, C, D, F, etc). You can have the group come to consensus on the grade, or you can have people write their grade on a piece of paper and then have the whole team reveal at the same time(similar to planning poker).
• I’ve used this pattern on two of the teams I’ve coached and it has had success. While I haven’t gathered empirical data on it, I did notice a marked increase in completion of retrospective action items.

Variations

• Review in the Sprint Review – In Jeff Sutherland’s Scrumming the Scrum pattern, which includes a similar practice of reviewing items each Sprint(he uses an impediment list instead of a retrospective action item list), he suggests presenting the results of the action item at the Sprint Review. I question that myself, because I don’t feel like the business stakeholders who represent users really care about the details of Scrum Team mechanics or Scrum Team improvements(especially when they are technical or development process oriented in nature). It also offers an opportunity for people not faimilar with intra team details a chance to give inappropriate or unhelpful feedback. On the other hand, sometimes user rep stakeholders can help resolve organizational impediments better or faster than technical folks. I suggest you decide which Scrum event is better for your team’s needs. Or, better yet, try both, then retrospect on the results!
• Retrospective Backlog(aka Improvement Backlog, similar to Impediments Backlog) — Make an ordered list of outstanding action items and review the list like a backlog at each retro. Order the list by perceived value to the team and/or organization. Update the backlog each retrospective with new action items and re-order as appropriate. Take on the top couple of items each Sprint to resolve them. Consider making a separate list of blocked action items. Sometimes a list of blocked items is helpful because a blocking condition gets lifted at a later date. At that point, the blocked item can be moved to the Restrospective backlog and ordered as appropriate. Making one or both of these lists visible to outsiders may spur help from an outsider with resolving an item.

Resulting context

• Teams actually improve more often and quicker due to heightened transparency on Retro action items.
  • Teams often get motivated by the amount of changes they’re able to make and making improvements becomes more of a habit.
  • Teams often have improved morale due to the empowerment they feel to self organize to make their team’s development processes smoother.

How do I handle production support on a Scrum Team?

Question: How should I handle production support on a Scrum Team that gets pulled off of new development every now and then to research/solve production problems?

This article is now deprecated in favor of this new article.

 

.

Sprint Tasking Tips: Team tasking strategies

Tip: Try to estimate tasks as a team.

Don’t take this the wrong way. I’m *not* suggesting that you all sit around a table and estimate tasks like Planning Poker or anything. Besides, Planning Poker is for sizing Product Backlog Items, not Sprint tasks. What I am suggesting is that when your team does Sprint tasking, generally in the Sprint Planning Meeting, allow the entire team to see the tasks and suggest modifications. Typically, with an experienced team, I recommend the team split up into pairs to create tasks for each Product Backlog Item. I then have the team re-join later and let the entire team view all tasks and their estimates. I then encourage the team to spend a short amount of time tweaking the tasks and estimates. Don’t fall into task analysis paralysis or anything, just give some short amount of time for some high priority tweaking. Whatever you do, don’t overthink task estimates! Just put something down quickly and then retrospect on it later.

---

Tip: Re-tasking mid-sprint is perfectly acceptable

It is perfectly acceptable to re-task one or more tasks mid sprint. Sometimes, you’re just not able to accurately predict the tasks for your sprint. The most important thing about your Scrum board is that it accurately reflects the work remaining in the sprint, to the best of everyone’s knowledge. I recommend you do not re-task alone. The tasks were originally created as a team in the Sprint Planning Meeting, so it’s important that you don’t re-design tasks alone. Consult with at least one team member when you’re doing this. Also, inform whoever updates your Sprint burndown so that the calculations stay correct. If the re-tasking is noteworthy, take 30 seconds to increase transparency by letting the entire team know about the re-tasking activity at the Daily Scrum.

---

Tip: Make sure the Team fully understands all Tasks

Sometimes a small sub-portion of the Team will do the initial creation and estimation of tasks. In these cases, make sure that the Team eventually takes a broad view of the Sprint Backlog before finishing the Sprint Planning Meeting. Near the end of the meeting is a good time to have the entire team view the entire Sprint Backlog and get clarifications make tweaks. Don’t get too caught up in the clarifications, of course. Whatever you do, don’t overthink tasks! Just create simple tasks and then retrospect on them later.

Link to full article:  Sprint Tasking Tips

What are your favorite Sprint Tasking Tips?  Post them in the comments.