Reader small image

You're reading from  The Professional ScrumMaster's Handbook

Product typeBook
Published inApr 2013
PublisherPackt
ISBN-139781849688024
Edition1st Edition
Concepts
Right arrow
Author (1)
Stacia Viscardi
Stacia Viscardi
author image
Stacia Viscardi

Stacia Viscardi is an Agile coach, Certified Scrum Trainer, and organizational transformation expert, devoted to creating energized and excited teams that delight their customers and inspire others. With humble beginnings in Port Arthur, Texas, Stacia found her niche as a Manufacturing Project Manager in the early nineties; she landed in the technology world in 1999 and never looked back. In 2003 she became the sixty-second Certified ScrumMaster (there are now over 200,000!), and founded AgileEvolution in 2006. She has helped companies such as Cisco Systems, Martha Stewart Living, Primavera, DoubleClick, Google, Razorfish, MyPublisher, Washington Post, and many others find their way to agility. Co-author of the Software Project Manager's Bridge to Agility, Stacia has taught Agile in 17 countries and is active in the ScrumAlliance as a CST and trusted community advisor. When she is not doing Agile stuff, she is training for a marathon or other long race or spending cozy nights on the sofa with her husband Chris, and dogs Jax and Cobi. A self-proclaimed process nerd, she loves helping teams and organizations discover the Scrum/XP/Lean mash-ups that enables focused, flexible, and fast delivery of products. She created the blog HelloScrum to share knowledge, tips, and tricks with Scrum practitioners, and co-founded KnowAgile, an Agile testing website. Stacia has co-authored The Software Project Manager's Bridge to Agility with Michele Sliger (2008, Addison-Wesley).
Read more about Stacia Viscardi

Right arrow

Appendix B. ScrumMaster's Workshop

This Appendix should be used as a companion as you read the book. As you go through each chapter, refer this section for additional questions and exercises to help you discover areas for future focus or improvement. You may also download this as a PDF at packtpub.com.

Chapter 1: Scrum – A Brief Review of the Basics (and a Few Interesting Tidbits)


  1. Explain the four pillars of Scrum and how they are interrelated.

  2. Describe an empirical process. How do the Scrum meetings, artifacts, and roles support empiricism?

  3. What happens when a Scrum meeting is dropped? What are the consequences or impacts when an artifact like the sprint backlog is missing?

  4. What makes your organization, your project, and your team complex?

  5. Which of the five Scrum core values (commitment, openness, respect, focus, courage) will be most challenging for you to personally adopt? Why?

  6. Which Scrum core value will your team be particularly challenged by? Why?

  7. Which Scrum core value will your organization be particularly challenged by? Why?

  8. Why should a sprint length, once determined, never be changed?

  9. Why is it so important that team members are not interrupted during a sprint?

  10. Is your team ready for Scrum? Why or why not?

Chapter 2: Release Planning – Tuning Product Development


  1. Congratulations! Last weekend, you and your significant other decided to get married and agreed upon a date two years from now, which gives you plenty of time to plan (and save some money!). What level of planning would you engage in today? Conceptual, like maybe a Star Wars theme or which venue should we visit, or detailed, like the bride should wear pink toenail polish and her hair in braids. Consider your initial planning approach, followed by more detailed levels of planning that you'd engage in as the wedding approaches. What information emerges through time? How does this affect your plan? Is the word "plan" more usefully thought of as a noun or a verb? Why?

  2. Think back to a recent surprise on a project that you were involved with. Was it preventable? Would thinking longer and harder about the problem have unearthed the issue sooner? Are all surprises avoidable? How does Agile say that teams should deal with surprises, via avoidance or embracement?

  3. Your senior architect is not very fond of moving to an Agile way of working. He balks and verbally resists Scrum in every meeting. He is concerned that attention to good architecture will be traded in for cowboy coding and hacks. How do you involve him in the team's discussions, yet not let his all-or-nothing approach hinder progress?

  4. How do story points and hours differ? How would you explain using both to a reluctant team? (This will happen, so please don't skip this question!)

  5. General tip: For all meetings, create scripts and agendas that keep things moving, ideally with as much team involvement as possible. Prior to the meeting, construct a storyboard of the meeting and identify what the actors will do in each scene, along with the necessary inputs and expected outcomes of each action. These scenes in your meeting storyboard provide an excellent start to your agenda and help you visualize your meeting as a movie ahead of time; this is a great use of your imagination to help you create a tangible, workable agenda!

Chapter 3: Sprint Planning – Fine-tune the Sprint Commitment


  1. The project manager and the marketing manager are arguing in front of the technical team about the importance and order of product backlog items. They've decided to combine their most important needs and have stated that they have 50 critical items among which the team may choose which to deliver in the upcoming sprint. What is wrong with this picture? How might you handle the situation?

  2. What tool does your product owner utilize for backlog management? Is the product backlog visible? Can anyone contribute to it? Does everyone know who the product owner is and what his/her responsibilities are? If the answer is no to any of these questions, please put an item on your Impediment Backlog to discuss and resolve this impediment.

  3. Let's say that your team suggested that instead of tasking stories out during sprint planning, they would rather individually send you their tasks before the sprint planning meeting in order to save time. This way you can just total up the tasks and hours for the team and let them know in the meeting if they are over or under capacity. They are excited about the time savings of this approach, but you have reservations about this. What do you tell the team?

  4. Please see the Sprint Planning Checklist in Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment. What steps would you expect that you could alleviate over time, given that your team remains the same sprint after sprint? What general ideas do you have to keep meetings light, focused, and efficient?

  5. During sprint planning, one of the team members wants to reprioritize stories because of some logical technical dependencies. What should the team do?

  6. You are interested to know if the team have reached consensus on the plan, so you ask the team their opinions. All the team members feel confident except for John, who is concerned as he feels the team has selected an amount of work that might turn out to be too much for the sprint time box. What can you do to help John feel comfortable about the proposed sprint commitment?

  7. While the team is tasking out the work, you overhear a lead developer assume that the feature should function a certain way, and then instructs everyone in the team accordingly. What is wrong with this situation, and how might you fix it on the spot?

  8. Are you a good facilitator? A good facilitator:

    • Understands the team, its lingo and jargon, behaviors, and history.

    • Creates a sense of safety; that is, everyone is free to speak his/her mind in a space that will kindly receive it. "Together, with everyone's participation, we can come up with an outcome better than what one person could create. Nobody will be talked down to, and there will be no condescending behavior."

    • Is like the Switzerland of the meeting, remaining neutral but not afraid to stop bad behavior or layer on knowledge. This does not mean to choose sides, but rather to make information and data available that might help the team reach a conclusion.

    • Spends adequate time preparing for the meeting, creating scripts, agendas, games, ice breakers—anything necessary to help the team meet the goal.

    • Has an arsenal of tricks and skills to pull on at any given moment should the meeting's attendees need a perk or conflict resolution.

    • Is skilled in conflict resolution.

    • Creates tools to help team members remember action items (clean up).

    • Does not cut off people as they are speaking, or finish others' sentences, or make decisions on behalf of the team.

  9. See Jean Tabaka's Collaboration Explained for more wonderful tips, tricks, agendas, and ideas.

Chapter 4: Sprint! Valuable, Collaborative, and Meaningful Work


  1. Are your team members dedicated to the team sprint after sprint? If not, add an item to your impediments backlog (IBL).

  2. Is the team made up of multiple disciplines so that they may deliver a set of fully tested features by the end of each sprint? If not, add an item to your IBL.

  3. Is your Scrum team Scrummerfalling, or doing some other weird form of Scrum? If so, add this item to your IBL and think about the discussion you'd like to have with the team in the next retrospective. Specifically, are they doing a Scrum hybrid due to a true constraint or an organizational dysfunction? Is a broader discussion necessary with management? How will you prepare for that discussion?

  4. Do you manage or direct the daily scrum meetings? What can you do to stop this? Are the team members getting into deep enough detail to truly synchronize? If not, how can you help? Are they going into too much detail? If so, how do you help them? Are they making obstacles known, or are they too shy? What can you do about this if you suspect they're not forthcoming with issues? Are team members willing to help each other solve their issues/impediments? If not, how can you encourage this behavior?

  5. Let's say that your organization does not have a trusting culture. How might you utilize the Scrum meetings to build such a culture? Are there any action items that you can come up with after thinking about this?

  6. Which of the four corporate culture adjectives— Collaborative, Creative, Competitive, Controlling—best describe your organization?

  7. If the organization does not value openness, respect, commitment, focus, and courage, how might this impact your team? What will you do about this? How will you tangibly know that you've made an impact on the organization's values?

  8. To what degree can you influence your peers, your team, your product owner, your manager, your VP, and your CEO? Which style might you choose to influence each type of co-worker (consider: demand, demonstrate, request, persuade, avoid).

  9. Which of the four legs of Scrum—self-managing, dedicated teams; time-boxing (sprints); prioritized product backlog; or inspect/adapt—will be most difficult to implement in your organization? Why?

Chapter 5: The End? Improving Product and Process One Bite at a Time


  1. Discuss with your team: what do they need to do in order to prepare for the sprint review? Would they like a practice run? Do they know who's demonstrating what? What were the big issues in the sprint that might be worth mentioning? What does your script look like?

  2. How would you go about preparing your product owner for the sprint review? What if he/she is not available to attend?

  3. What do you feel is the single most important metric to give at the sprint review? Why?

  4. You notice that your team is unhappy because stakeholders asked for changes in the functionality as a result of the sprint review. You, on the other hand, are quite happy about this. Why is there a disconnect between you and the team? What do you feel they're most concerned about?

  5. What observations did you make about the team during the sprint? When do you feel would be the right time to bring up your observations? Put yourself in the shoes of the team member as you consider the answer to this question.

  6. What if part of your team is offshore and follows a command-and-control culture; therefore, they are terrified of speaking up in the retrospective? What can you do to help them feel safe to speak up?

  7. After a few retrospectives with your team, you've noticed that one team member is especially profound with his ideas for change. That is, he has some great ideas, but most of them probably won't pass muster with the rest of the organization. How do you keep him engaged and speaking up even though most of his ideas are too progressive for everyone else? You certainly don't want to shut him down!

Chapter 6: The Criticality of Real-time Information


  1. A vision exercise. I like Geoffrey Moore's vision statement from Crossing the Chasm. One way to make sure everyone on the project team gets the Level 1 magnification is to hand them each a blank sheet of paper and ask them to write the vision statement; it's fine for team members to pair up or work in small teamlets of three. After 15 minutes have each pair/teamlet read its version of the vision statement. Responses that are similar reflect a good communication and understanding; vastly different responses signify that the vision should be revisited. What natural opportunities are there for restating the project vision throughout the Scrum project? When might the vision need to change? What happens when there is no vision statement? (Note, if you do not currently have a vision statement for your team's project, please add this to your impediment backlog as something that should be resolved with the product owner as soon as possible. If you do not have a product owner, that's another item for your list with an action to find a proxy at least for the short term.)

  2. How can you ensure that the product vision stays visible and fresh in every team member's mind?

  3. What do you do if the product owner does not have a vision statement? To whom might this issue need to be escalated? What specific actions can be taken to ensure that the team has a well-stated vision?

  4. Referring to the Gantt chart view in this chapter, would this be necessary for every team and every project? In which situations would it not be applicable? Is this a view you would want to provide?

  5. The team wants to add tasks to the product backlog. What's wrong with this idea?

  6. The product owner is frustrated that the team says, "We only do release planning for three months into the future because we're Agile." The product owner needs a forecast for eight months in order to win a contract. What can you do? What are the pros and cons of planning so far ahead and basing a monetary exchange off of this plan?

  7. When might a team not need a sprint burndown chart?

  8. Let's say that your team likes the idea of a 55" LED monitor in the team room to project their sprint metrics and your manager approved budget for it. But the team is worrying too much about the perfect set of metrics causing them to stall out on making anything visible at all. Which one or two bits of information would you encourage them to start with? How would you ensure that the job gets done?

  9. Scrum focuses more on real-time broadcasting versus distributing reports; however, which reports (the static kind) might be helpful in your environment?

  10. How might you kick off the Management Scrum or WORST (Waste and Obstacle Removal Scrum Team)?

Chapter 7: Scrum Values Expose Fear, Dysfunction, and Waste


  1. How does the Definition of Done incite organizational change? Cross-functional, dedicated teams? Product backlog? The role of the ScrumMaster?

  2. Are you a ScrumMaster by mistake, choice, or design? Did you realize just how important the role of the ScrumMaster is? Do you think you can carry out the responsibilities of this role?

  3. What are your personal strengths that will aid you in the role of ScrumMaster?

  4. What are your weaknesses? Can you add these to your impediment backlog in the personal category so that you can work on them? How will you know that you've successfully conquered these weaknesses?

  5. What personal convictions do you repeatedly compromise at work? Why? How does this make you feel? What is the ultimate consequence of this compromise? What can you do about it?

  6. Run a waste exercise with your managers; if you're unsure about this, practice it with the team. Use the waste worksheet from this chapter to quantify the wastes in traditional software development as a template. Put dollar signs to the final numbers. Shoot holes in it. Is this something you might feel comfortable presenting to management? If you're really feeling courageous, give the department a waste score (from Chapter 9, Shaping the Agile Organization)

  7. What is initially costly about moving to a dedicated, cross-functional team model? What are the benefits gained from these costs?

  8. Do you have a "personal board of directors"—people whom you trust to give advice that will help you reach your goals? If not, put a list together. Approach each person with why you'd like their mentorship, the goals that you have for yourself, along with your initial plans to get there. Ask if they can agree to check in with you once a month to give feedback, criticism, and suggested next steps.

  9. Tell your story and suggest that team members do the same. As you begin to make progress and see a shining light at the end of the tunnel, ask the team if anyone would be interested to present their story at an Agile conference. There are many smaller groups (as well as international events!) both in person and virtual that love to hear success stories. This can be very motivating for teams!

  10. When's the last time you said "no"? When is the next time you might be able to? Can you commit to saying it?

  11. When is the next time you can serve your team? Maybe it's by bringing snacks to the next meeting, standing up and facilitating, helping the team drive to a resolution. Identify the next opportunity, put it in your calendar, and commit to do it.

  12. Have you self-actualized? Review the checklist in Chapter 9, Shaping the Agile Organization. Answer each on a scale of 1 to 5 (1: barely satisfies; 5: completely satisfies). If your total is between 44-55, you are in the self-actualizing zone. If your total is around 11-20, you have some work to do today. Highlight the lowest-scoring attributes and pick one to start on today. Write them all in your impediment backlog in the personal category and seek opportunities to practice these characteristics. Sometimes the best way to create permanent and lasting change is to fake it until you make it!

  13. When you feel comfortable, have a heart-to-heart talk with your team about your department's performance review process. What works well? What hinders people? What suggestions do you have for improvement? Then, talk to other ScrumMasters. Put together a formal proposal for managers and HR for changes in the performance review system that would enable higher performance and risk-taking in individuals and teams. Start from the ground up.

Chapter 8: Everyday Leadership for the ScrumMaster and Team


  1. What's your personality style? Go out and take the Meyers-Briggs assessment if you haven't already. Which traits will help you as a ScrumMaster? Which traits might hinder you?

  2. Talk with others. Get feedback about your performance during meetings with respect to your verbal and written styles, effectiveness of communication. See if you can tease out criticism and areas for improvement. Don't forget to celebrate the things that you do well.

  3. Set up a bi-weekly leadership meeting with fellow ScrumMasters. Identify books to read, blogs to follow, things to try. Report back to each other, critique each other, help each other improve.

  4. When you feel threatened, what makes you feel this way? Is it a person? A communication style? A situation that brings out feelings of inadequacy? Once you've identified the trigger for your feeling, try to pinpoint why you feel this way. Are you afraid of losing? Appearing dumb? What reasons do you have for feeling intimidated in certain situations? Are these reasons legitimate? Even if they are, there must be one thing you can do to start to change the situation. Maybe it's your reaction. Identify and practice it.

  5. Pay attention to what you say for one week. Write down every statement that you make that has a negative twist. Evaluate this at the end of one week; did you have many? Did these tend to fall within the same categories?

  6. Do you have a Scrum buddy? Get one if not?

Chapter 9: Shaping the Agile Organization


  1. Where does your loyalty lie? Are you dedicated to your team and team members' happiness or are you too worried about what your manager thinks?

  2. How can you get management to accept that a Scrum team makes its own rules and essentially governs itself? What if management cannot accept this?

  3. Are your team members able to focus? Or are they being pulled in too many directions?

  4. Are you completely focused on your team? Laptops closed, mobile phone off? Undivided attention? Observe yourself. Give your team your full attention; ask them to respect each other and do the same. If the meetings are taking too long, discuss ways of shortening.

  5. When is the next opportunity for you to share something with your team that they may not expect? Maybe it's something you learned from a management meeting that you feel your team might be interested to know. Perhaps the product owner keeps stopping by your desk to discuss user stories and you feel the team might like to be pulled into that conversation. Start breaking down barriers to visibility and free communication. Identify these small opportunities that make large strides in openness and trust.

Chapter 10: Scrum – Large and Small


  1. Do you feel that if you're truly performing the role of the ScrumMaster that you would have time for more than one team? Under what circumstances might you?

  2. Let's say you have a team of 13 people, each with a very narrow specialty. Scrum is causing difficulty as the team seems too large. What other alternatives are there?

  3. How does a product owner ensure that quality is good when there are multiple teams involved in developing one product? What's the ScrumMaster's role in this?

  4. Who attends your Scrum of Scrum meeting? Based on what you've learned in Chapter 9, Shaping the Agile Organization, is this the right set of attendees?

  5. Does your team or teams have a Definition of Done? If not, please find the next immediate time to discuss this

lock icon
The rest of the chapter is locked
You have been reading a chapter from
The Professional ScrumMaster's Handbook
Published in: Apr 2013Publisher: PacktISBN-13: 9781849688024
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime

Author (1)

author image
Stacia Viscardi

Stacia Viscardi is an Agile coach, Certified Scrum Trainer, and organizational transformation expert, devoted to creating energized and excited teams that delight their customers and inspire others. With humble beginnings in Port Arthur, Texas, Stacia found her niche as a Manufacturing Project Manager in the early nineties; she landed in the technology world in 1999 and never looked back. In 2003 she became the sixty-second Certified ScrumMaster (there are now over 200,000!), and founded AgileEvolution in 2006. She has helped companies such as Cisco Systems, Martha Stewart Living, Primavera, DoubleClick, Google, Razorfish, MyPublisher, Washington Post, and many others find their way to agility. Co-author of the Software Project Manager's Bridge to Agility, Stacia has taught Agile in 17 countries and is active in the ScrumAlliance as a CST and trusted community advisor. When she is not doing Agile stuff, she is training for a marathon or other long race or spending cozy nights on the sofa with her husband Chris, and dogs Jax and Cobi. A self-proclaimed process nerd, she loves helping teams and organizations discover the Scrum/XP/Lean mash-ups that enables focused, flexible, and fast delivery of products. She created the blog HelloScrum to share knowledge, tips, and tricks with Scrum practitioners, and co-founded KnowAgile, an Agile testing website. Stacia has co-authored The Software Project Manager's Bridge to Agility with Michele Sliger (2008, Addison-Wesley).
Read more about Stacia Viscardi