Scrum.org Professional Scrum Master II (PSM II) Exam Study Tips

1. Read and thoroughly understand/internalize the Scrum Guide. Read it several times in different sittings. We recommend that you download the PDF and read it like you would a book. Over, and over again!
2. Take the Scrum Open assessment numerous times. Get to where you can take it 5 times in a row and score 100% each time, in about 10 minutes or less each time. VERY IMPORTANT – DO NOT SKIP THIS STEP.
   • Yes, we know there are a lot of repeat questions, but you will need to be able to quickly answer these questions when time is short on the real assessment
   • For each question that you miss, read the feedback given by the assessment on that question. Then, look in the Scrum Guide for specific language OR just Scrum principles and concepts that support the correct answer. Analyze what makes all of the other (wrong)answers seem inferior.
   • In between “5 times in a row sessions”, read the Scrum Guide again.
   • Do not assume that the real assessment is of the same difficulty level as the practice assessment. The real assessment is definitely much much harder.
   • If you find you are completely stumped, post a question on the Scrum.org forums.
     • Note that posting Scrum Open questions is fine, but do NOT post real assessment questions on the forum — that is against forum rules.
3. Read about Burndown Charts here and here.
4. Read the Scrum Glossary, and refer back to it when necessary.
5. If you took a Scrum.org class (which is quite helpful, but not required), review the slides, workbooks, your notes, etc from that course.
6. Warning: There are 3rd party companies (i.e. outside of Scrum.org) that provide practice tests and test preparations for this assessment. In our experience, while they are mildly helpful, they will steer you so wrong on the understanding of Scrum sometimes that we recommend against even considering them. We recommend you definitely don’t use them to prepare.
7. When taking the test, scribble a few notes about questions that took you a long time to answer or you felt like were very challenging. This will help you to study in case you need to re-take the assessment later. Remember that you can re-take the assessment for $250 more. Go here to purchase another attempt if you like.
8. Assume that there are no “perfect” answers… Only “best” answers — when wearing your “Scrum Principles Wizard” hat. Answer as if you were the author of the Scrum Guide yourself.
9. If you haven’t already as part of the PSM I prep, purchase and read Hiren Doshi’s Scrum Insights for Practitioners Book. (Like all books on Scrum, this book is not perfect, but there is a ton of awesome info in it and it is far better than any other book on the market to help you learn Scrum tactics and prepare for this test.)
10. Read my article on Emergent Architecture
11. Read my article on the The New New Product Owner
12. Follow step 2 above, except using the Product Owner Open assessment.
13. It’s important to note that it will be very difficult to pass this exam without a year or more of good Scrum experience. It’s even more helpful if you have worked in multi-team/scaling scenarios or have even more experience. Of course, if you don’t pass the first time, you can always re-take the exam for $250. Just go here and purchase another attempt
14. Be prepared for long questions and answers: Many of the questions have several sentences of scenario set up — be ready to absorb that context and use it when answering the questions. In addition, many of the answers to questions are long as well — make sure you are in a very quiet environment so that you can think deeply about those questions and answers.
15. Several questions will have multi-team and scaling aspects to them. You do not need to know any specific scaling framework, but you will need to know how to apply the Scrum Guide and its principles to those multi team scenarios. Hint: there are some multi-team principles/rules in the Scrum Guide. Hint 2: Many Scrum principles are easily applied to multiple teams. See my article on the Scrum of Scrums for one example of that concept.
16. Time management: Ideally you will have finished all of the questions and have some time left over to re-check them. Re-visit as many questions as possible, looking for things you missed in the question or making sure your answer corresponds to the question or scenario being presented. Utilize every minute you have in the time-box to ensure your answers are the best ones.
17. If you have some months before you plan to take this test,we suggest attending and engaging in Scrum user groups and conferences- go there, listen to people describing their challenges, and then think of how empiricism and self-organization, as described in the Scrum Guide, would suggest approaching the challenge. If the answer is not clear, post the scenario and the options you can think of, on the Scrum.org forums and take a look at the responses you get.
18. If you have not attended a “Professional Scrum Master” course, then this step is required.
    1. Purchase and read the Scrum Pocket Guide
    2. Read and follow the Scrum.org forums. Pay close attention to those posters who seem very knowledgeable or have a high number of posts shown under their user name on the forum.

 

When You’re Ready…

When you’re ready to take on the assessment, use the discounted attempt you were emailed by Scrum.org as a result of your attendance in the class. Or, if you didn’t attend a Scrum.org class, go here and purchase an attempt. It’s that easy!

Other Useful Links

• Thinking of taking the Professional Scrum Product Owner (PSPO I) assessment at Scrum.org? See here for study tips for that assessment.
• If it has been a while since you took the PSM I test, then prepare by taking that test again ($150) or prepare by following the PSM I Study tips

The End of Kurt Cagle: Or At Least the End of his Movie Studio Model.

Disclaimer Up Front:  I have been “Crazy” about Scrum since I first learned about it, and I myself have been known to act a little “Crazy” at times in my life, and this is why my blog and company operate under the “ScrumCrazy” brand.  That, and in the world of SEO, it’s easier for people to find my articles if they put the word “Crazy” in their search engine queries along with the word “Scrum”.  While I was personally interviewed, trained, and certified as a trainer by the co creator of Scrum, Ken Schwaber, (through his valiant organization, Scrum.org), none of what I say below is me speaking on behalf of Ken, Scrum.org, or anyone else.  For those who don’t know, Ken was also an Agile Manifesto signer and one of the chief visionaries of that artifact(I was told this by others, not Ken).    But having said all of that, These are my own thoughts and opinions, and are not endorsed by anyone but me.

(The title of this article is a play on words from Kurt’s first article.  I do not wish any type of “end” whatsoever to Kurt Cagle. )

In Kurt’s first article, he does a great job on three fronts:

1.  He does a wonderful job of setting up a straw man argument against Scrum… oh wait, more like a straw man argument against “not Scrum,” as we trainers sometimes like to call it.  The experiences he describe are 100% clearly of people who don’t understand Scrum or the Agile Manifesto in any meaningful way.  They are doing what Martin Fowler calls “faux Agile,” as Scott Heffield so politely put it in his pretty good but oh so polite rebuttal.  The only thing I can add to Scott’s rebuttal is that we Trainer/Coaches see this archetype in industry often — someone experiences “faux Scrum”, and assumes that was real Scrum, or even professional Scrum.  I don’t know Kurt, but usually this archetype of a person never bothers to crack one of the leading Scrum books or goes to get a good certification class in Scrum or goes to a good Scrum conference– they would rather just criticize from the cheap seats without doing any sort of deep dive.  Maybe that’s Kurt maybe it’s not — I’m only speaking to the archetype, not to Kurt personally.  I’ll let him explain his credible or not so credible learning journey on Scrum prior to his first article.
2. The other thing his first article does well is that at the end of it, in one of the edits, he realizes that Scrum and Agile are not quite the same thing, but then he makes the argument that at many organizations, they are synonymous.  He is partially right about that, for reasons I will expound upon later below.  But here’s the thing, anyone who comes to my 2 day Scrum classes learns the difference between Agile and Scrum on day one, so here is another data point that tells me he likely has not done his homework on Agile and Scrum — and that’s fine, he’s on a learning journey, and all of the inbound traffic he has gotten after the first article will get him up to speed pretty quickly.
3. He does a great job on getting 300K hits.  Does this speak to motive?  What is he hawking in his non journalism job?  Is it a “studio model” perhaps to replace Agile? Is this a sales pitch for his non journalism work? Speaking of motive, one could make similar arguments about me.  Is Charles trying to promote his Scrum classes?  Is he trying to “piggyback” on 300K likes so that Charles will get more than the 16.5 blog readers he currently has?  Fair arguments, but I can tall you first hand I’m not doing it for those reasons (but I’ll happily accept 1.5 more blog readers or anyone who wants to request a Scrum class)  🙂

In Kurt’s 2nd article, he does basically two things:

1. He pitches his “movie studio model”, and
2. He tries to bash Agile (or is it Scrum?) some more.

I’ll take on the 2nd thing first just a bit, because honestly, I almost agree with him on #1, but more about that later.  Skip down below to “Movie Studio Model” if you want to see that next.

In trying to sideways bash Agile, he says

1. “Vision Is Critical. …(e.g., software) ultimately is the reflection of one person’s vision. That person is the one who determines the boundary of the work…but that particular person ultimately is responsible for both the initial direction and design of the project, and in many respects is also responsible for ensuring that the resulting product reflects the best potential product it can…”
   1. Hmm.  He pretty much described the “Product Owner” role in Scrum to a tee.  I will admit that the Agile Manifesto does not speak much to that unifying vision, other than some sideways references.
2. “Good Design Is An Absolute Requirement. The Agile Manifesto gives short shrift to design,”
   1. Hmm, well, ok.  But the Agile Manifesto is short, basically 4 value statements and 12 one sentence principles — far below the # of words in your article, sir. So, short shrift… maybe… but Agile Manifesto principles 8-11 have everything to do with Design.  I will admit that principle #10 doesn’t look like it has to do with design, but it does.  I know this because I asked a forum question to one of the Agile Manifesto authors(Jeffries) at a conference.   And I also read a ton of articles on similar Agile subjects.  But that’s because I went on a learning journey rather than thinking I could understand such a powerful artifact from only reading it.  So, sorry, Kurt, not buying your “short shrift” argument.  Is it possible you just don’t understand the Agile Manifesto deeply?
3. I could go on an on like this all day about his article, but that would be super boring.  Heck, I’m lucky 4.2 of you are still reading this.  🙂
4. Let’s just wrap this section up by saying Scrum and Agile are often treated as synonymous, but that’s just by people who have never bothered to do the research and learn.  The other reason this is true is because, in modern times,  90% of Agile Teams are actually Scrum teams.  I would argue that Scrum is the wildly most successful of all Agile frameworks, and that’s why 90% of Agile Teams are Scrum Teams.  I would further argue that no one in history since the Agile Manifesto was written has ever created a highly successful, full on, Agile framework, that was NOT based on Scrum.  Try to prove me wrong.  <insert internet prove me wrong meme here>  🙂  In short, Kurt, you are correct that they are treated synonymously, but that’s only because of the massive success of Scrum, an Agile framework.  🙂  Ergo, due to the success of Agile.

Movie Studio Model

Here’s where it gets interesting to me.  Kurt, your movie studio model is decent, but it has one fatal flaw.  Movies are generally one and done, good software products are not.  Also, even if you make the argument that movie franchises are a better model, there is such a huge gap of time between movies in a series that your metaphor breaks down again.  Great software products do not go on long hiatuses like that.

It’s not a Movie Studio, it’s more like a TV Studio, and a TV Series

I like your model, but the hiatus flaw doesn’t work for me.  For years I have pondered how a great software product is very much like a great TV series (aka “Web series” to you Gen Z types).  There is usually a pilot or a small first season, what we in Agile software call either an MVP or a some early form of Lean Startup validations.  The series usually pursues a lucrative profitable market(or creates the same), what we call in Agile “business value”, as supported by the target market — Personas, User Roles, and/or Stakeholders.  I’m not as familiar with TV studios, but I’m guessing some combo of the Head Writer and Exec Producer fulfill that Product Owner visionary role — trying to maximize the business value of the software product (or TV series) with a “see the whole” type vision.  Most great TV series last 7 or more years, and usually have profitable spinoffs (and maybe even a couple of dud spinoffs).  Guess what also has these characteristics?  A great software product!  The Director is fairly close to the Scrum Master role, except it would have to be a director who is very collaborative and doesn’t use command authority — think of a great director who really cares about the growth of his actors and in harnessing their creativity– a true servant leader.  That would be a decent Scrum Master.  As all metaphors do, lots of things break down from here.  The only other good connection here for me is that, while the actors/Scrum Team members might change over the years, the PO keeps a close eye on the story arcs, and everyone tries desperately to continue to extract business value out of their target market.  And, at some point, sometimes apps and TV shows get “played out”, and it’s time to start over again with something new and fresh.  On the other hand, sometimes there are true spinoffs or other kinds of derivative products that are offshoots of great products.  A big problem with the studio metaphors is it requires way too many people to be successful.  Good Agile teams can be highly successful with just 7 or so players.  That’s extremely rare in a TV series or a movie.

But here’s the interesting part for me.  I was once a programmer like you, Kurt, and you want to know how I came to this TV studio metaphor that’s so similar to yours?  Not through my years as a programmer consultant — through Agile practice and attending Agile conferences.  Ohhh the irony!

So, Kurt, you were close, but you are on a learning journey so keep plugging away.  And not for nothin, but so am I.  If there is one thing I’ve been taught in the Agile space, it’s that we are never at perfection.  We are always improving.  You keep on keepin on!

 

 

More Aspects of Agile Communities of Practice

This is a follow up article to my article about An Agile Community of Practice Starter Kit.  I wanted to share some details on other aspects of CoP’s.

Scope and Nature of a CoP

The scope of an Agile CoP can be of varying sizes and types. The most typical are (most frequent, to less frequent): Organization wide, Localized to a set of teams(Train, Product Group, Nexus, etc), Geographical location, and Organizational department. Organization wide CoP’s tend to be more educational and inspirational in the theme of their activities, while CoP’s localized to a set of teams tend to be very operational in nature. But truth be told, a single CoP can have all 3 of these themes in flight at any one time, only one of those themes in flight, or they could evolve from one to the other, etc.

Educational themed events include webinars and other similar education events, and even providing access and funding for people to attend training or conferences in the community interest. Another educational themed event could be a book club or a study group for achieving industry certifications.

Inspirational themed events includes meetings and other events that are meant to inspire people in the community interest. Some examples:

• An event to inspire attendees to develop a set of skills in the community interest
  “We’re looking for employees who are interested in being Scrum Masters”.
• An event to inspire community members by allowing attendees to be inspired by the success stories from others who have skills in the community interest.
  • “In today’s session, we’ll have 3 Product Owners talk about the very different ways the 3 of them go about Product Backlog Refinement, and all 3 ways are highly successful for their respective teams. We’ll wrap up with how the principles for all 3 are the same, even though the practices are quite different.”
• An event to inspire community members towards personal development in their community interest.
  • “In today’s session, we’re going to talk about a myriad of ways to develop yourself personally as a programmer, as well as some examples to give to your reporting manager so these ways can be included in your quarterly talent development goals. We’d also like to hear some of your ideas on this topic!”

Operational themed events include meetings where inflight product development work or impediments are being discussed. Some examples:

• Scrum of Scrums
• Scrum Master Sync (this and Scrum of Scrums are actually different)
• Nexus Daily Scrum
• Product Owner Sync
• Meta Scrum
• Program Increment Planning (yes, this is actually a very operational Community of Practice if you think about it!)
• Internal Open Source Component Rollout (Internal Open Source Communities are a great way to preserve shared code without having to use component teams)
• Internal Open Source Component Brainstorm Session
• Architecture Advancement Meeting
• Tiger Teams (these are usually short lived Communities)

Work efforts as a result of Community Improvement Backlog Items

One thing to keep in mind about operationally themed events and communities is that all work on the system/product under development still happens on Scrum Teams. Think about production code. If production code is to be written as a result of a Community effort, a Scrum Team must do that as part of their Product Backlog and/or Sprint Backlog. Any other type of work or improvement that doesn’t require production code can be done in a group of motivated like minded community members, or can also be done as part of a team’s Sprint Backlog. As long as it’s not production code, you have total flexibility in how you organize that non production code work.

Regardless of their scope or theme of events, CoP’s should have regularly scheduled retrospectives, regularly scheduled public meetings, and probably also need regularly scheduled private meetings(usually limited to role-players only, but could be other sets of people). As I said in my /CoP starter kit article, a CoP should also have a bunch of Community Working Agreements, a Community Improvement Backlog(CIB), and official communication mechanisms(formal and informal). All of those things still apply of course, regardless of the scope of a Community.

Roles

Community Coordinators(CC)

The coordinators act as the organizers of the CoP, and the main facilitators. One of the principles of a CoP is that you want to build an organization that is more bottom up than top down. Many organizations are coming from strong top down hierarchies. As such, the coordinators must come from the Scrum Dev Teams. You definitely want 2 of them to ensure continuity, and in case they get themselves on the critical path on their Scrum Team or take vacation, etc. At first, they could serve a 3 month term, but once the CoP has been in existence for about a year, you could experiment with a longer term if the community decided to change that agreement. Ideally, at least one of them is more junior, and there is no requirement that the CC be deeply skilled in the community interest. (Remember, there is a different role for skill depth: the SME’s) We’re focused more on people who will inspire community involvement and will responsibly handle community logistics/coordination (aka “social butterflies” and “workhorses”).

When you are bootstrapping the community, give some attention to trying to find a couple of good choices for the initial CC’s, and if they agree to take the role, it is theirs! After the bootstrap, going forward, elections are held halfway into the term of the current position holder so that a nice transition of responsibilities can happen. CC’s should give special consideration to the fact that someone else will likely hold their role soon, and that someone else might completely change direction from the practice or style that you preferred when you were the position holder. To the extent possible, any community formality of any kind should be kept lightweight, easy to transition, and likely to have a long life. This helps ensure smooth continuity rather than volatility in how the community operates. To the extent possible, the CC’s should encourage bottom up self organization of the community. They should also obtain feedback from the community, but if guardrails or executive decisions are needed, the CC’s have the final say over all other positions in this community. Also worth noting that this community likely operates in a wider context (usually a company/org), so all company policies and company leadership roles must be respected or the community faces the prospect of being shut down. The community should feel free to (respectfully!) challenge the status quo of the wider context to increase value delivery, but only respectfully and diplomatically. Bottom up self organization does not mean your community “runs” the company. Role playing note: While not encouraged, only one of the CC’s may hold another position in the same community, and when they play dual roles, they must always clarify which role their input is originating from.

Management Sponsor(MS)

The management sponsor helps get funding and other logistics approved for the community. Ideally, but not absolutely required, the MS is a fairly high up leader in the organization that oversees the community interest. This role is also optional, as a strong community in an organization that empowers communities might not even need a management sponsor.

Artifacts

Community Working Agreements

Your community will likely have some “Community Working Agreements”

Example CWA’s: (We agree that…)

1. The community has 2 “Community coordinators”(CC) who serve 3 month terms.
   [The CC role’s mission is to incubate and inspire self organizing improvement efforts that further the “community interest.” They generally do this via ensuring that logistics flow smoothly and that benefits(improvement value) from “individuals and interactions” are maximized in the community.]
2. CC’s must also be Scrum Dev Team members.
3. It is strongly discouraged to have a CC who resides on more than one Scrum Team. (too much multi-tasking, and residing on two Scrum Dev Teams is weak Scrum practice anyway)
4. Elections for all positions are held half way into the current term to help provide continuity and orderly transition to the new position holders in the community.
5. A maximum of one CC can also hold another position/role in our community.

Hopefully you now have a better picture of some other aspects around CoP’s.

Scrum.org Professional Scrum Master II (PSM II) Exam Study Tips

You may notice that steps 1-10 are a re-hash of suggestions for studying for the PSM I exam. If you took PSM I recently, then just quickly re-do these steps again (or skim instead of read, etc). If you didn’t take PSM I recently, then you probably need to do all of steps 1-10 again to help get you ready for this exam. Regardless, we highly recommend you don’t skip steps 1-10 below under any circumstances.

1. Read and thoroughly understand/internalize the Scrum Guide. Read it several times in different sittings. We recommend that you download the PDF and read it like you would a book. Over, and over again!
2. Take the Scrum Open assessment numerous times. Get to where you can take it 5 times in a row and score 100% each time, in about 10 minutes or less each time. VERY IMPORTANT – DO NOT SKIP THIS STEP.
   • Yes, we know there are a lot of repeat questions, but you will need to be able to quickly answer these questions when time is short on the real assessment
   • For each question that you miss, read the feedback given by the assessment on that question. Then, look in the Scrum Guide for specific language OR just Scrum principles and concepts that support the correct answer. Analyze what makes all of the other (wrong)answers seem inferior.
   • In between “5 times in a row sessions”, read the Scrum Guide again.
   • Do not assume that the real assessment is of the same difficulty level as the practice assessment. The real assessment is definitely much much harder.
   • If you find you are completely stumped, post a question on the Scrum.org forums.
     • Note that posting Scrum Open questions is fine, but do NOT post real assessment questions on the forum — that is against forum rules.
3. Read about Burndown Charts here and here.
4. Read the Scrum Glossary, and refer back to it when necessary.
5. If you took a Scrum.org class (which is quite helpful, but not required), review the course materials and your notes from that course. If you need a Scrum.org class or an Agile/Scrum class of any kind, contact us!
6. Warning: There are 3rd party companies (i.e. outside of Scrum.org) that provide practice tests and test preparations for this assessment. In our experience, while they are mildly helpful, they will steer you so wrong on the understanding of Scrum sometimes that we recommend against even considering them. We recommend you definitely don’t use them to prepare.
7. Experience is one of the best ways to be prepared for this exam.  We can’t give you that here, but just wanted to note that.
8. When taking the test, scribble a few notes about questions that took you a long time to answer or you felt like were very challenging. This will help you to study in case you need to re-take the assessment later. Remember that, if you don’t have a free extra attempt(you get up to 2 attempts if you attend the PSM II class) you can re-take the assessment for $250 more. Go here to purchase another attempt if you like.
9. Assume that there are no “perfect” answers… Only “best” answers — when wearing your “Scrum Principles Wizard” hat. Answer as if you were the author of the Scrum Guide yourself.
10. If you haven’t already as part of the PSM I prep, purchase and read Hiren Doshi’s Scrum Insights for Practitioners Book. (Like all books on Scrum, this book is not perfect, but there is a ton of awesome info in it and it is far better than any other book on the market to help you learn Scrum tactics and prepare for this test.)
11. Read my article on Emergent Architecture
12. Read my article on the The New New Product Owner
13. Follow step 2 above, except using the Product Owner Open assessment.
14. It’s important to note that it will be very difficult to pass this exam without a year or more of good Scrum experience. It’s even more helpful if you have worked in multi-team/scaling scenarios or have even more experience. Of course, if you don’t pass the first time, you can always re-take the exam for $250. Just go here and purchase another attempt
15. Be prepared for long questions and answers: Many of the questions have several sentences of scenario set up — be ready to absorb that context and use it when answering the questions. In addition, many of the answers to questions are long as well — make sure you are in a very quiet environment so that you can think deeply about those questions and answers.
16. Several questions may have multi-team and scaling aspects to them. You do not need to know any specific scaling framework, but you will need to know how to apply the Scrum Guide and its principles to those multi team scenarios. Hint: there are some multi-team principles/rules in the Scrum Guide. Hint 2: Many Scrum principles are easily applied to multiple teams. See my article on the Scrum of Scrums for one example of that concept.  You might also take a look at the Nexus Guide and Nexus Open.
17. Time management: Ideally you will have finished all of the questions and have some time left over to re-check them. Re-visit as many questions as possible, looking for things you missed in the question or making sure your answer corresponds to the question or scenario being presented. Utilize every minute you have in the time-box to ensure your answers are the best ones.
18. If you have some months before you plan to take this test,we suggest attending and engaging in Scrum user groups and conferences- go there, listen to people describing their challenges, and then think of how empiricism and self-organization, as described in the Scrum Guide, would suggest approaching the challenge. If the answer is not clear, post the scenario and the options you can think of, on the Scrum.org forums and take a look at the responses you get.
19. If you have not attended a “Professional Scrum Master I” course, then this step is required. If you have attended that course, then find and study the course materials and consider that these two suggestions below as being recommended.
    1. Purchase and read the Scrum Pocket Guide
    2. Read and follow the Scrum.org forums. Pay close attention to those posters who seem very knowledgeable or have a high number of posts shown under their user name on the forum.
20. If you have attended a “Professional Scrum Master II” course, study the course materials and your notes.  If you have not attended PSM II, then be sure you do the vast majority of this list!
21. Make judicious use of “the process of elimination” of answers.  Many incorrect answers will display one or more Scrum dysfunctions or just be totally incorrect Scrum, which might help you narrow down the remaining list of best choices to choose from.

 

When You’re Ready…

When you’re ready to take on the assessment, use the discounted attempt you were emailed by Scrum.org as a result of your attendance in the class. Or, if you didn’t attend a Scrum.org class, go here and purchase an attempt. It’s that easy!

Other Useful Links

• Thinking of taking the Professional Scrum Product Owner (PSPO I) assessment at Scrum.org? See here for study tips for that assessment.
• If it has been a while since you took the PSM I test, then prepare by taking that test again ($150) or prepare by following the PSM I Study tips

User Stories to Represent Backend Services, Web Services, SOA, etc

Sometimes you have a need to represent User Stories that describe a back end service, API, web service, or similar.

First of all, a couple of warnings.
1. Make sure that you’re not creating a “Technical Story”. Technical Stories are a misunderstanding of the User Story practice. See trap#5 here.
2. If your team regularly creates “back end service” stories, it is likely that your team could be a Component Team, and having too many component teams in an organization can greatly harm agility to the point that your organization operates more like waterfall than Agile. See this link for more on that subject: https://less.works/less/structure/feature_teams.html
3. If a single team feels the need to create both a “back end story” and a “front end story”, or anything similar to that (Technical Story + Business Story, etc), then you are likely implementing the User Story practice wrong. This is an indicator that you’re doing horizontal slicing instead of vertical slicing. See trap#5 here

The only time that a back end story is really a true user story, is when your team is a component team(your team can’t deliver an end to end user visible feature), OR when your team works on a product that is a web service or API that is sold or used outside of your company.

So, with all of those caveats, here is my advice for creating these kinds of stories.
1. The acceptance criteria should only describe the UI. Note that I didn’t say GUI — I said UI. The UI for your web service is it’s api or service signature. This typically includes input variables(payload), output variables, exceptions, and/or error codes. Describe this input/output data in business terminology whenever possible!
2. Avoid describing anything beyond the API in the user story, but do describe the logic of how the inputs are processed. Again, use business terminology, something a business user would understand, whenever possible.
3. These kinds of stories lend themselves quite nicely to acceptance criteria that are represented using the Specification By Example techniques (see the presentation link at top, page 26 and beyond in the PDF), since those always describe expected test inputs and expected test outputs. Further, you can slice these stories quite thin since you can use the various data scenarios to slice the story and still have end to end functionality(request/response) delivered.
4. In terms of identifying a user role or persona, it would be nice if you could refer to an end user of your service who is a human if at all possible. If you don’t have line of site to the real end user, you can always just refer to a user role of “API user” or something. But again, all of the above caveats apply.

Back End stories also mix nicely with this non traditional Agile User Story slicing model, as usually your system acts as both a downstream(request) and an upstream(response) system.

The Best Scrum Product Owner Book Ever Written!! (Must Read for PO’s and Agile Coaches)

Full disclosure: I actually sometimes compete against Don, one of the authors, for Scrum Coaching and Training work, so while we are friendly, we are also competitors in the marketplace. People who know me know that I “call ’em like I see ’em.” In a way, giving a positive review for Don’s(and Ralph’s) book is actually against my own interest. But I don’t care, darnit! This work of art is too important to our industry. I hope you will take this review as high praise from a competitor, because that’s what it is.  I make no money off of this article or the link below.  My review is completely objective.

Amazon Link:  http://a.co/d/dMkuhWo

The book is hands down the best Scrum Product Owner book ever written. Period. The End. Ok, not the end… I’m waaaayy more wordy than that. This is a must read for all PO’s and Agile Coaches. So many other people focus on “writing stories” and other menial parts of the Product Owner role, while totally glossing over the most important role of the PO, that of maximizing the value delivery of the Scrum Team’s product. The authors’ Vision, Value, Validation mantra (The 3 V’s) throughout the book is an absolute game changer, and what the PO role is all about. It’s about darn time someone wrote about that! How about how to “define a product” when trying to use Scrum? The authors hit this head on. They hit so many other important topics head on. My favorites: Products not Projects, Defining and Measuring Value using straightforward value metrics, molding yourself into the “Entrepreneur” PO, structuring your teams to avoid the *component team* nightmare, several *different* MVP patterns, Cynefin, Risk management in Scrum, Ready and Done, Quality management and why the PO should care, release strategies, Story Mapping, and a ton of anti-patterns and how to guard against them. They wrap it all up with your journey from a “Receiving product Owner” to how you can turn yourself into an “Initiating Product Owner.” As if this all wasn’t good enough (and I only named *some* of *my* favorite topics!), they tell numerous anecdotes, each one of them a true, in-the-trenches, in-the-field, experience, that teaches you a lesson so you won’t have to learn that the hard way. They have culminated all of their awesome experiences and wrapped them up in a tidy bow in this book. I am truly jealous of this work. It is that good! Buy one for yourself, and then buy one for your manager too, because he or she needs it. Trust me on this. You won’t regret doing that.

It is my opinion that any credible review should include criticism and other proof that the review writer is objective. So, here goes… I’m not sure Eric Ries would be thrilled with their use of the MVP term and how Scrum is essentially a framework for creating “a series” of one MVP after another, for the *same* product. Metaphorically I get where they are going and it totally makes sense, but the “telephone game” in our industry is rampant, so I wish they could have come up with a way to describe this using new or different terminology. Most of my other suggested improvements are very tiny things. For instance, they say that the “stakeholder” role is not an official role of Scrum. I disagree with that, in large part because they might be the most important role in Scrum! I feel like I know what they were trying to say. I think I would re-word that as “the stakeholder role is not one of the 3 main roles that are most discussed in Scrum, but they play a huge part in value delivery…”

And finally, to once again assuage anyone’s fears that my objectivity is limited here, I will say that Roman Pichler’s book on the PO role is good, and it was, in my opinion, the best PO book available prior to this one. Roman is a trainer with a competing Scrum organization to mine. His book was written a full 8 years ago, and the Scrum Guide, Scrum framework, and scaled Scrum Frameworks have undergone numerous significant updates and changes since then. I honestly hope that Roman writes a new edition of his book and I hope it gives this one a run for its money! That would be wonderful for everyone involved! (and I will write him a glowing review if he does!) So, if you want to buy two books on the PO role, buy this one first, then Roman’s book. As another way to show that I’m objective, I also recommend Ilan Goldstein’s “Scrum Shortcuts without Cutting Corners”. Ilan is also from a competing Scrum organization to mine.

One other last note. This book will definitely help you prepare the right mindset if you want to take the PSPO I certification exam assessment from Scrum.org. Honestly, there are several much better reasons to read this book than to get certified. But it will help you, if certification is part of your learning plan. In my opinion, this book alone is insufficient to pass the exam, but it was not intended as an exam prep. This book is a great companion to your learning plan. If you want to study for that exam, do a google search for “PSPO study plan” or something. Having said all of that, read the book because you want to become, and help others become, a kick arse Product Owner, because that’s what this book appears to be intended for.

Product Backlog Refinement Tips (formerly called Grooming)

Executive Summary

In this article, I discuss some tips for how to do effective Product Backlog Refinement.  “Refinement” is the new term in the Scrum Guide for what used to be called “Grooming” — this changed in 2011 in the Scrum Guide. The primary benefits of backlog refinement are increased productivity, increased understanding/quality, and prevention of delays due to unknowns. Backlog refinement can be a little difficult at first when getting started, but the benefits are large and they appear very quickly, usually after just a couple of Sprints of doing it.  The goal of Product Backlog Refinement is to get Product Backlog Items (PBI’s) that are “Ready” (shared understanding, acceptance criteria, sized) to be brought into a Sprint.  Items are usually brought into a Sprint at Sprint Planning, but they can also be brought in mid sprint at times.

Learn more about great Product Backlog Refinement practices in our /Agile Requirements and Product Owner Techniques classes.

Some Assumptions of this article

• There are several kinds of Product Backlog refinement, but in this article, I will focus almost exclusively on Weekly Team Product Backlog Refinement, except as otherwise noted.
• I use Scrum terminology and a 2 week Sprint cycle in this article, but you can translate these concepts to other software approaches and iteration lengths.
• I will use the more generic Product Backlog Item(PBI) term here, except where I make special mention of User Stories. Pretty much everything in this article also applies to User Stories.
• Synonyms for Product Backlog Refinement: backlog grooming, sprint preview meeting, user story grooming, detailing user stories, story writing workshop, user story conversations, etc
• Any time I mention “backlog”, “backlog item” or “item” in this article, I’m referring to the Product Backlog and *not* referring to the Sprint Backlog.

Tips for Effective Backlog Refinement

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team’s circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

Tip – a practice that is definitely worth consideration, but might only be good in a few or very specific contexts or team situations.

---

Tip #1: Try to never schedule backlog refinement during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog refinement.

---

Tip #2: Treat the backlog refinement meeting just like the first part of the Sprint Planning Meeting

• Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
  • The PO or Dev Team member presents the backlog items (often User Stories), the rest of the team ask for clarifications, and then the items are estimated by the team.
    • The PO then or later might indicate that the order will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

---

Tip #3: Make sure the PO knows that, during all of this sprint’s backlog refinement sessions, they will be expected to present enough work to last about 2 Sprints *beyond* the current sprint.

The reason for bringing this much work to the meeting is two fold:
1. Often times PBI’s will be reordered based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.

• One common reason: External dependencies, or coordination with another group outside this team.

2. It’s a good practice anyway to have some finely refined PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 2 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning, PI Planning, or other meeting or in some other backlog refinement discussion meeting. If not, then the PO can discuss the new PBI with a team member or two (informal product backlog refinement) to get a feel for the very rough effort involved (but be sure not to communicate this rough estimate to the team — don’t want to anchor/skew their initial estimates!).

---

Tip #4: The backlog items should be fine grained and well understood by the PO or a Dev Team member for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO or a Dev Team member brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist (or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance criteria for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance criteria are high level, that is better than no acceptance criteria at all. The more the PO and team focus on getting to good detailed acceptance criteria, the better.  Also, see Story Testing Patterns.

---

Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the backlog refinement and the time the item is brought into a Sprint, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip…

---

Tip #6: Make sure everyone understands that Product Backlog order is not final until a PBI has been accepted into a sprint.

The PO is free to change the order of the backlog between the backlog refinement and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big ordering changes happen rarely between the backlog refinement and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change order often, remember that this kind of information is something we want sooner rather than later.

---

Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and “Ready” to roll into a Sprint, and also has, in total, enough for the next two sprints beyond the current one. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow? and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprints. This brings us to our next tip…

---

Tip #8: Assign action items for any big risks or unknowns

For big requirements issues, this probably means assigning the issue to the PO. For big technology risks or unknowns, this means assigning a dev team member to research the issue at hand. The person assigned should be ready to report on the action item at or before the next refinement meeting or definitely before the item is brought into the Sprint. This will usually involve re-estimating the item based on the new information — and that’s perfectly acceptable. Who does the assigning? In general, to support self organization, the PO and Dev Team members should volunteer to take an action item. The Scrum Master can help by asking questions like: “Who can take this one on and get back to the team on this?”. Avoid having any one dominating person assigning action items to people — that’s not very self organizing.

---

Tip #9: Remember that backlog items (and/or User Stories) are a collaboration between the PO and the Dev Team

The final responsibility for making sure the PBI’s are adequately detailed for the development team’s use falls on the Product Owner. However, don’t take that to mean it’s the PO’s job to do all that work. The items should be the results of a collaboration between the PO and the dev team(and also probably between the PO and the customers or end users). It is perfectly acceptable, and in fact encouraged, that the PO meet with 1, 2, or all members of the team to help detail a PBI, prior to a refinement session (what I call “informal backlog refinement”). It is also perfectly acceptable if Dev Team members do the vast majority of refinement activities in direct consultation with users and stakeholders. Schedule meetings or have spontaneous collaborations as necessary, with the end goal being a well thought out, well detailed PBI when it is presented at a backlog refinement session. It is very atypical for a PBI to be one that is new to every single developer(The Scrum definition of “developer”) at a backlog refinement session. If this happens, consider it a bad smell and try to get developers involved earlier.

We highly recommend that you read the “Product Backlog Management Leader” section in our very best article on the Product Owner role: The New New Product Owner.

(Worth noting here, the Scrum Master has very little role in Product Backlog Refinement.  Their only real role is to teach the team how to communicate PBI’s with the PO, and how to execute efficient refinement.  Once this is accomplished, the Scrum Master will not attend refinement very often)

---

Tip #10: Remind the Dev Team to review the PBI’s to be discussed about 24 hours prior to the refinement session.

If your PBI’s are documented in any way before a backlog refinement session (such as in a tool,on a wiki or on index cards), send a reminder to the dev team to review them so they are prepared to speak intelligently about them.

If the PO is making lots of last minute edits right up until the refinement session, much of the information will be seen for the first time in the meeting, which can make the meeting last longer and be more confusing. Ideally, the PO and Dev Team should target their editing efforts at being ready 24 hours prior to the backlog refinement session.

---

Tip #11: Definitely feel free to split PBI’s during this meeting.

If anyone on the Scrum team feels the need to split items, during a refinement session is a perfect time to do it. You’ll probably want to re-estimate them too, and that’s fine. I hope it also goes without saying that if you split an 8 point PBI there should be no emphasis on making sure that the split out PBI’s all add up to 8 points. Just re-estimate them as if they were new, independent, PBI’s.

---

Tip #12: Optimize your time in the meeting.

For PBI’s that are well defined, just discuss and quickly estimate. For PBI’s that have already been discussed in a previous refinement session, you only really need to revisit them if there is new information about them. For PBI’s where there is new information, just discuss the new information enough to be able to give a new estimate.

---

Tip #13: Don’t be afraid to discuss a couple of items that are farther down the backlog

Sometimes there will be a need to discuss a backlog item that is further down the backlog. Here are some reasons for doing that:

• The PO needs to gauge the rough size of a PBI
• The dev team needs to identify external dependencies that will need to be started on ASAP while waiting for the rest of the item’s details to be flushed out.

There can be many other reasons, too. While we don’t want to get into a habit of doing BRUF (Big Requirements Up Front) or BDUF (Big Design UP Front), there are rare situations where looking at a backlog item that is farther down the road is advantageous to the team and the organization as a whole. Don’t be afraid to do it, but be wary of slipping back into BRUF and BDUF.

---

Tip #14: Strongly consider doing some informal backlog refinement before the full team backlog refinement.

• Informal Product Backlog Refinement
  • The Product Owner or Dev Team members will work with zero or more dev team members or stakeholders to refine stories and their order in the backlog. Said another way, this is a lighter more informal way to refine the items in much the same way the refinement is done in the Weekly Team Backlog Refinement. This kind of informal refinement should be a daily, if not hourly, occurrence for the Product Owner and Dev Team.
    • When the PO gets together with development team members (early collaborators), she should strongly consider making sure that the three amigos are there.
      • Also feel free to bring stakeholders in to discuss.
    • Development team members should feel free to discuss relative sizes with the PO, but I encourage teams to wait to record any estimate until the entire team has estimated the item first. Said another way, the early collaborators should try to avoid skewing or anchoring the entire Dev Team’s estimates.

---

Tip #15: Don’t be afraid to introduce late breaking PBI’s. Try to minimize them, but embrace them when they happen.

Remain Agile! Some of the major goals around doing backlog refinement are to reduce unknowns and risks, but not all risks are easily identifiable beforehand. Backlog refinement is not meant to eliminate risks, only to minimize them. Late breaking PBI’s will probably still happen (hopefully rarely), and they should generally be welcomed by the team. On the other hand, if it seems like most of your backlog items are late breaking, that is generally a bad smell.

---

Tip #16: Typical Meeting Attendees: Dev Team, the PO, and rare appearances by other key people

On rare occasions, you will need other key people(end users, stakeholders, architects, etc), but prefer keeping other non Scrum Team members out of the meeting as a general rule unless they have a very specific reason to be there. But certainly do empower the Scrum Team to invite whoever they think will be helpful — people outside the Scrum Team should be “invited” by the Scrum Team — as needed.

---

Tip #17: Experiment with the amount of refinement that your team does.

In the beginning, until you get “two sprints ahead” (beyond the current sprint), you will need more refinement than normal. After you get caught up, experiment with how much refinement is usually needed to stay “two sprints ahead.” When I coach teams, I usually tell them that 1-2 hours per week is typical, and that until they are “two sprints ahead,” they should double that amount. Don’t use these numbers as hard and fast rules, but instead as a starting place to adjust the time up or down as needed. The Scrum time-box for refinement is 10% of the Dev Team’s time per sprint. For a 2 week sprint, that means the equivalent of 1 full day (8 hours) per sprint for every Dev Team member. I find that most teams can stay well under that time box once they’re “two sprints ahead.”

---

Tip #18: Be sure to retrospect, inspect, and adapt!

Just like every other Scrum practice, it is absolutely imperative that your team inspects and adapts their practices. If your team feels like backlog refinement is a waste of time, then there are almost assuredly impediments that need removing. Do a “Five Why’s” analysis and read up on good backlog refinement techniques.

---

Learn more about great Product Backlog Refinement practices in our /Agile Requirements and Product Owner Techniques classes.

Conclusion

If backlog refinement is done well, you can skip the entire “What” part of the Sprint Planning meeting and go straight to decomposing PBI’s in the “How?” part of the meeting. How’s that for a short planning meeting? Most teams will find that having regular product backlog refinement increases overall team knowledge and eventually increases productivity, usually by a large factor.

An Agile Community of Practice Starter Kit

As I describe in my article An Agile Architecture Community of Practice, a very mature Community of Practice has mechanisms that represent that the community has come to agree upon, over a long period of time.  Those standards and working agreements need to mature over time as well…but what if you’re starting a new Community of Practice(CoP) from scratch and you’re NOT mature yet?  Where do you start?

To me, the healthy starter kit for a CoP is comprised of the following:

• The Community forms around an ” improvement interest” or effort that spans across multiple teams(Release Train, Product Group, Nexus, etc), that is scoped according to improvement domain, and also possibly according to organizational domain, geographic domain, and or product(system under development) domain.
• Roles: The following positions or roles need to be initially filled:
  • Community Agile Coach
    • fulfilled by an Agile Coach (and/or Scrum Master), absolutely required position, also good to have a “backup” at all times as well.
  • 2 Community Coordinators
    • Both of these coordinators must come from Scrum Development Teams*
      • * Exception:  if the community “improvement interest” is a topic whose “home base” is not on a Scrum Dev Team, then this requirement is waived.  For instance:  Scrum Master CoP, Agile Manager CoP, Agile Executive CoP, are not home based in Scrum Development Teams
      • The coordinators are responsible for ensuring the “communication mechanisms” below are bringing maximum value to the community.
  • 2-4 Subject Matter Experts
    • These people are the people that are most passionate about the subject that the community is formed around.  They typically already share their knowledge across their teams and/or organizations, and are looked up to widely across the Scrum Teams/and or org.  Ideally they come from Scrum Teams, but this is not a hard requirement, and sometimes difficult to fulfill in orgs that are relatively new to Agile.
  • 1 Management Supporter(optional)
    • This is optional, and should only be fulfilled if you can find someone with good Agile behavior(preferably someone with at least one Scrum or Scaled Scrum/Agile certification, preferably both), and communicate to this person that, in the community, they MUST act as a servant leader to the community, and must let the other roles run the community without too much influence or direction coming from the Management Supporter.  The management supporter might be more directive outside the community activities, but not through the community mechanisms.
• Artifacts: The following artifacts are required:
  • Community Improvement Backlog
    • Unlike the Product Backlog in Scrum, this Community Improvement  Backlog (CIB) contains Community Backlog Items (CBI’s) that only represent “improvements” in the community’s “improvement interest.”  There may be Product Backlog Items that represent work on the Product under development that come out of a community’s efforts, but those will land on a particular Scrum Team’s plate(even if the item applies across several teams).  Remember, bring the work to the (already existing) Scrum Teams and put it on the Product Backlog!  The CB only holds community improvement ideas, not product development work.
    • Obviously, this artifact only needs a couple of items on it to start.
  • Community Working Agreements
    • Agreements about how your community will operate.  (This is the CoP version of  the “Team Working Agreements” in Agile)  The people who fulfill the above roles(the “role players”) are responsible for ensuring this happens.  Many of the other things listed here in this blog post could be your starter set for CWA’s(Roles, Artifacts, Events, Communication Mechanisms).
    • TWA #1 should be something like “In everything we do as a Community, we try to honor the Agile Manifesto.  So, we value individuals & interactions over processes and tools, we value responding to change over following a plan, and we value executing improvement experiments over endless theoretical discussion and “analysis paralysis” about how to go about improving.”
• Events:
  • Meetings at least 3X a month, including at least one meeting open to the public. (Some meetings are best held more privately among the role players in the community, to help coordinate all efforts, public and private)
• Communication Mechanisms:  The following comm mechanisms should be established from the beginning.  The Community Coordinators are responsible for ensuring maximum value is continuously obtained from these comm mechanisms.
  • Synchronous “push” communication for spontaneous collaboration:
    • If everyone is highly co-located, then the mechanism is “Talk to each other”
    • If not, then this mechanism is something like an “always on” videoconferencing system, but also could be a chat room (think Slack or HipChat)
    • Email is a very poor form of this mechanism, but if you can’t get something like the above, then an email list may be the best you can do right now.  (IF that is the case “Find a better Synchronous Communication mechanism” should be high in your community’s improvement backlog)
  • Asynchronous “collaborative” communication for longer lived communications
    • A wiki (something like a Confluence or MediaWiki)
      •  At a minimum, your wiki (and it’s sub pages) should document
        • Your Community’s mission/interest
        • Your CB or a link to your CB (possibly kept in another tool, but a wiki is ok for this purpose too)
        • Your CWA’s
        • The description of the current position holders
        • Info about how to get onboarded to your community’s communication mechanisms.
    • Last resort:  If you can’t get a wiki, an “opaque” document repository mechanism (such as Sharepoint, Google Docs, Dropbox or your code repository)  can be used to keep documents that the community can use, store, and access.
    • (optional) A “work board” for more tactical coordination and possibly the Community Improvement Backlog.  (Something like Trello, a wiki, or your favorite Agile life cycle tool if you can get your company to give you a separate project area for your efforts)  If you can’t quickly get this, this might be a CBI.

The above is the basic starter set to get a Community of Practice started.  Something not mentioned above is the intended audience for the community.  The community is led by the role players, BUT the beneficiaries and implementers of the improvements are generally the “grass roots” members of the community, such as members of your Scrum Development teams.  Said another way, there is a vital implicit role in a Community of Practice, that of  the “target audience” for the community’s efforts.  When the community has “public” meetings, or other communications sent via public communication channels, the target audience benefits greatly from the improvements made by the community.

For me, there are always at least 3 CoP’s that are needed in every environment where multiple Scrum or Agile teams work together closely on a product (aka system under development).

1. Agile Architecture Community of Practice
2. Agile Testing Community of Practice
3. Cross Team coordination Community of Practice (This one often already exists in your scaling framework, such as Scrum of Scrums, Nexus Daily Scrum, Nexus Integration Team, System Team, and there are many other examples)
   1. These practices are really just narrow CoP’s that focus on “Coordinating the flow of work to maximize the value delivery of frequent software releases”

At this point, you may be asking yourself “Why this many roles and structure just to get started?”  Here’s the reason:  Until you have the “minimum viable practice” in place, you should not start a Community of Practice.  You are creating a C-O-M-M-U-N-I-T-Y.  With any fewer than the above roles, artifacts, events, and communication mechanisms fulfilled, you won’t likely have a chance of creating a long running effort that is sustainable, productive, and beneficial over a longer period of time.  If you can’t convince the above handful of people to take a leadership role, then you have more work to do and more support to gather before starting.

For some more info on CoP’s, see this follow on article:  More Aspects of Agile Communities of Practice

The emphasis for your community should always be on “executing improvements” over having endless “how we run the community” process discussions or “how we should go about improvement X” discussions.  Remember, “individuals and interactions over processes and tools.”  🙂

 

Story Testing Patterns

Be sure to remember to mix and combine the patterns as necessary!
You can also download a One Page PDF or view the Story Testing Patterns Presentation that goes along with this summary.

Pattern	Generally Good For…	Generally Bad For…
<“Test that…”>	Beginning Story Testers Simple Tests Tests hard to describe using the other patterns	Experienced Story Testers that know a better pattern. Tests with a lot of setup logic or behavior logic(try a different pattern) Tests where behavior depends on numerous test inputs
<Given/When/Then>	Tests that require a lot of preconditions or setup, OR setup that is important or easily forgotten Tests that have a specific, non obvious trigger Tests where there are few expected outputs	Tests that have unimportant/simple/obvious preconditions Tests where there are multiple different inputs and multiple different outputs Tests where a single Given/When/Then only describes one of numerous very similar test scenarios
<Specification By Example – Conceptual or Concrete>	Tests that have numerous: Inputs that affect output behavior Outputs/expected behaviors Tests where it’s important to test a lot of different data scenarios Tests where the trigger event is somewhat obvious Any test where it seems like a table would be useful to: describe the test better, or help explore all of the possible inputs and outputs for a test.	Simple tests Tests that are more about verifying simple UI behavior For instance – “Test that an error message is displayed when the user enters an incorrect password.” Test where there is really only one input or precondition
<Bullet Points>	Teams that are highly co-located with PO Stories that are very small(2-3 days) Tests that are very simple Tests with fairly obvious expected behavior	Distributed Teams Stories that are large (which is a bad habit anyway) Tests that are not simple Tests with non-obvious expected behavior
<“Test With…”>	Teams that are highly co-located with PO Stories that are very small(2-3 days) Tests that are very simple Tests with fairly obvious expected behavior	Distributed Teams Stories that are large (which is a bad habit anyway) Tests that are not simple Tests with non-obvious expected behavior
<Flow Charts>	Tests where the flow of behavior is very complex, and easier to represent with a series of successive questions/answers	Generally bad for everything else.
<State Diagrams>	Tests where a system object can go through numerous (often workflow related) states	Generally bad for everything else.

Remember to strongly prefer index cards(5×8), wiki’s, and whiteboards(take photos!) over ALM tools and other electronic documents/tools.

You can also download a  One Page PDF version or view the Story Testing Patterns Presentation that goes along with this summary.

Agile User Story Slicing – An Alternative to the Vertical Slicing Metaphor for Valuable User Stories

Vertical slicing is a decent metaphor for how to ensure that User Stories are indeed valuable to users and key stakeholders. However, I’ve found it a little bit lacking for more complex systems, especially ones that also have upstream and downstream systems that the system under development interacts with. Cases where this model is especially useful is if your Scrum Team is doing internal software, /System Integration, Business Intelligence/Analytics, and web services(ReST, SOA, etc) or Microservices. Typical User Story practice encourages us to /create stories with INVEST qualities. The practices below will help you do so, and help you connect better with the “V” part of the story, the part that means that story is Valuable to users and /key stakeholders. It will also help you with the other letters in that acronym too. But we’ll focus on the V.

Rather than rely on the vertical slicing metaphor, I’m starting to teach more and more of my coaching and training clients the “System Boundary” view of story slicing. In this model, I tell them to draw a line around their system, and then consider the system boundaries, labeled SB1-SB4 below.

System requirements are best captured at the system boundary. As such, User Story Acceptance Criteria (and indeed their associated Acceptance Tests that are preferably automated) should document what happens at the system boundary, and no further.

Some Anti-Patterns
For instance, in my coaching travels, I have seen people creating “Analysis Stories”,”Technical Stories”, “Testing Stories”, “Back End Stories”, and “Integration Stories.” Nearly always, these are people who struggle with how to “slice the cake” to design a User Story that is truly Valuable, as in the INVEST acronym.

Sometimes, a team is very limited by the stories they can create because they are a component team, and are not able to create an end to end feature like feature teams can. In scaled Scrum implementations(several teams working on the same product/system), some organizations have remnants of waterfall still in their organizational design and team structure, such as a large organization composed almost exclusively of component teams. It’s important to keep an eye out for this “too many component teams” anti-pattern — it can be quite devastating to productivity and value delivery.
For more info see “WODA” in this article about the Top 10 Challenges to Scrum that Organizations face. But with that caveat out of the way…

Great Agile User Stories will hit the system boundaries at least TWICE!

The boundaries of the system(or product, as we say in Scrum) under development are shown in the graphic above. SB1-SB4 represent the system boundaries, where we interface with our key stakeholders (humans, as well as upstream and downstream systems, who have humans that represents the interests of those systems). A good Agile User story will hit those boundaries twice. For instance, the typical “vertical slice” in a typical software application with a GUI will hit system boundaries SB3 and SB4. Sometimes, upstream data will somehow get surfaced in one of a product’s GUIs — so it will hit system boundaries SB1 and SB4.

Example: System Integration (Vendor sold product that your org integrates into it’s internal systems)

Another example might even hit all 4 boundaries! These are pretty typical with /Scrum Teams that do System Integration. Some data could flow in from an upstream system(SB1), be presented in a product’s GUI(SB4) for some sort of approval or tweaking(SB3), then approved and sent to the downstream system(SB4). (But of course, this might be better split into 2 stories that each hit 2 boundaries each)

Example: Web Services

It’s important to note that in this model, the upstream system and downstream system could be the same system. Imagine your product is a back end payment system for a retail web site, and that your back end system had no real GUI, just web service endpoints (ReST, SOA, etc). In that case, the “upstream” system would send a payment service request to your system(SB1), and then your system would do some processing on it, and send it back to the (now considered) “downstream” system (SB2) with an approval or denial code or similar. Note that the upstream/downstream system might be in your org, or it might be external (what web services is really built for). It’s again important to note that if you have /”back end stories”, you probably have component teams. Again, not all component teams are evil, but having too many of them in your organization is pretty damaging in terms of agility and productivity. See “WODA” in this article about the Top 10 Challenges to Scrum that Organizations face.

One other related note is that if you’re implementing Scrum, the people that represent those upstream and to downstream systems(usually Dev Team members of those teams) should be involved in your Product Backlog Refinement and Sprint Reviews, so that they can collaborate about boundaries SB1 and SB2. In essence, these Dev Team members for the upstream/downstream systems are key stakeholders for your system.

In Summary
So, if your User Stories don’t touch the system boundaries at least twice, then strongly question whether you have sliced your story correctly to have “value” or not. Chances are, you haven’t — so look at other ways of slicing and dicing that User Story(see the links below for more help with slicing).