Skip to main content
    Do you need a Scrum Master?

    5 ways to be a great Scrum Master

    Even the best Scrum Masters can often find ways to improve themselves, the team and the product. Below are a few tips that might help you become a better Scrum Master. Let me know in the comments what you think of these tips and feel free to add your own.

    Listen to understand, not to reply

    listen
    Listen, Understand, Act by Steven Shorrock / CC BY-NC-SA 2.0

    Most people do not listen with the intent to understand; they listen with the intent to reply

    – Stephen R Covey.

     

    Most people only listen to others so that they can respond and get their own point across. This doesn’t allow the speaker to be truly understood, which might be vital to solving their problem or helping them. To be a true servant leader Scrum Master, you must put your own priorities at the bottom of the queue when listening to a team member. Only when you have fully understood someone’s issue, can you begin to help them.

     

    Check in not just to find out about progress, but to become aware of impediments so they can be removed.

    A great Scrum Master can check in with staff to get a progress update, without micro managing them. While getting an update of progress is fine, go further by offering to remove any impediments that may exist.

     

    Celebrate and showcase the team’s success

    A great Scrum Master ensures that the whole organisation knows about the team’s successes and the effort that was required by them to achieve that success. This not only motivates the team, but it also highlights the benefits of Scrum to the organisation. This is especially useful where the organisation has just started its agile journey and is expecting to see the benefits of it.

    As Scrum Master, remember that you helped the team achieve their success, but they achieved it.

     

    Get out and about to remove impediments

    It’s easy for people to ignore the emails you send to them, but it’s more difficult to ignore you when you’re stood right next to their desk. When you need to remove an impediment, sometimes it can be more effective to go and see someone in person. Not only should you get a more prompt answer, but you’ll get an insight into their situation – perhaps they are facing an issue which in turn means that they can’t help with your issue.

     

    sailboatHave a variety of Retrospective techniques

    To ensure that Scrum Retrospectives don’t get stale, it’s important for the Scrum Master to have a variety of techniques/formats for conducting this meeting. Whether it’s Start, Stop and Continue; the Sailboat or something a little different such as Lego models or the Constellation Game, having a variety of formats not only keeps the Retrospective fun and engaging, but also provides opportunities for all team members to express their views.

    How to pass the Professional Scrum Master (PSM I) exam

    scrum training seriesScrum Training Series videos

    When I first started fulfilling a Scrum Master duty, I found the video training series by Michael James to be a great resource. The videos add a visual element that you don’t get with the Scrum Guide, and really help you picture the activities of a real-life Scrum team. Also, depending on your learning style, you might prefer to learn by watching videos, rather than reading text.

    The mini tests at the end of each chapter are a great way to check your knowledge.

    Scrum Training Series

     

    scrum guideThe official Scrum Guide

    Following a general introduction to Scrum through the above training series, you really need to get an understanding of the official Scrum Guide. You’ll likely need to read it quite a few times to ensure you understand and remember it. Although the PSM exam is open book, the time limit means that you won’t have the opportunity to look through the Scrum Guide for an answer.

    How you best learn the Scrum Guide depends on your preferred learning style. Perhaps you just want to read the Guide over a few times, or write down its points on paper to help you remember. I used the two methods above, in conjunction with the audio book version: Scrum Guide Audio Book.

    This allowed me to concentrate on the words of the guide while blocking out any distractions.

     

    Additional Learning – Nexus

    Nexus is the Scrum.org version of scaled Scrum. You may get one or two questions on your exam about Nexus (as the questions selected are randomised, you don’t know for sure if you’ll get any Nexus questions).

    I recommend reading over the Nexus Guide to get a basic understanding of it.

     

    Mock Exams

    Once you have become more familiar with the Scrum Guide, it’s useful to try some practice tests. This gets you familiar with the format of the questions and how much time you have to answer them. The Scrum Open Assessment even features questions from the actual exam, so if you ensure that you can repeatedly score 100% on this text, you’ll be in a good position for the real thing.

    A more extensive exam is the one created by Mikhail Lapsin: PSM I Quiz. This has the same number of questions and time limit as the real exam. Although the questions are not exactly the same as on the official exam, they are very close. This quiz also has a learning mode, where each question has an explanation – this is very useful for reaffirming your knowledge, or understanding why you got a question wrong.

     

    The PSM I Exam

    • Have a copy of the Scrum Guide available in case you need to refer to it. However you’ll only have enough time to use it once or twice.
    • Make sure you read the questions properly. Often there may be a negative word in the question i.e. “Which of these is not…”
    • You should have enough time to go back and check your questions. If you finish early, make sure you do this.
    • You can flag any questions that you’re not sure about, to make it easier to return to them.
    • Make sure you answer all the questions, even if you’re not sure of which option to pick.

     

    I hope this post has provided you with some useful resources and tips. Let me know how you get on with your PSM I exam, and Good Luck!

     

    Building a Wallboard in JIRA

    What is a Wallboard?

    A wallboard is a type of information radiator that displays information about the progress of the development team. Traditionally these would comprise a physical board, with sticky notes, printed charts, etc. But with JIRA, we can create a Wallboard that can be easily edited and will update automatically.

    What is an information radiator?

    An information radiator is a large, easy to see, display of data that is accessible to everyone. It provides people with the data they need, without having to ask questions and so improves communication without requiring interruptions. A good information radiator:

    • Is large and easily visible to the casual observer
    • Is understood at a glance
    • Updates periodically
    • Is easily kept up to date

    Creating a Wallboard in JIRA

    First create a Dashboard

    JIRA allows you to create wallboards that look great on large screens, have easy to read Gadgets and update automatically.

    1. First you need to create a Dashboard that will hold the Gadgets and display the data that you want. The dashboard is what you see when you first login to JIRA. You can’t edit the default dashboard, but you can create a new dashboard based on it, or create one from scratch.
      1. From the top right of your Dashboard, click on the three dots 
      2. From the dropdown menu, click on Create dashboard to create a blank dashboard, or Copy dashboard to create a copy of the current dashboard.
      3. Fill in the details as appropriate – you can choose who this dashboard should be shared with e.g. a group, project, any logged in user or public. Click Create.
      4. By default the dashboard is created with two columns, but you can change this by clicking on the Edit layout button in the top right.
      5. We’ll stick with the default two columns.
    2. Next we’ll add Gadgets to our dashboard that will display the data.
      1. You can either click the Add gadget button in the top right of the page, or click on Add a new gadget in the relevant box.
      2. You’ll then be presented with the list of available gadgets.
      3. You can add any Gadgets that you like to your Dashboard, but those in the Wallboard category have been optimised for display on a Wallboard.
      4. When you add a Gadget, you’ll be shown some configuration options. These will vary depending on the type of Gadget.
    Which Gadgets should I add?

    To create an effective wallboard, I like to add the following Gadgets:

    • Days Remaining in Sprint – simply shows the number of working days left in the current Sprint (or another Sprint that you select).
    • Agile Wallboard – shows your Scrum board.
    • Sprint Burndown – shows the burndown chart for your current (or selected) Sprint.
    • Sprint Health – shows your overall Sprint progress based on the time elapsed, work completed and work remaining.

    Once you’ve added the required Gadgets, your Dashboard will look something like this. You can drag and drop Gadgets to rearrange them.

     

    Gadget colours

    Note how the gadgets each have a header with a colour – currently blue. Gadgets in the same column and with the same colour will only display one at a time, but will rotate out every few seconds. If you want to display all the gadgets in a column at the same time, edit their colours.

    Viewing as a Wallboard

    Once you’ve created your Dashboard, simply click on the three dots in the top right again and select View as Wallboard. The data on your Wallboard will automatically update based on the settings you chose.

     

    The Scrum Master should elicit feedback from the team to determine if the Wallboard is displaying the required information. If not, it can be adapted to meet their requirements and using JIRA this is easy to do.

    JIRA vs physical Scrum board

    There is often discussion in the Scrum community over whether a physical or electronic (e.g. JIRA) task board is better. In reality they both have advantages and which you prefer will depend on your team. Below I look at some of the advantages of each.

    JIRA

    Automatically create reports and charts

    One of the main advantages of JIRA is that it automatically creates reports for you so you don’t have to collect the data manually. When using a physical board and you want to create a Burn Down Chart, you have to know when a task has been Done and record its story points. You also have to bear in mind how your chart will be updated and displayed – if you’re using a paper chart, you’ll need to print a new one every day.
    With an electronic board, the charts are updated instantly and you can adjust their parameters to easily see the data you want.

     

    Add comments/attachments to a task

    Physical task cards/sticky notes don’t have any space for additional comments, documents or images, so these must be stored in another way. An electronic board can show/hide information as required and adapt its display to show this information. This can make it easier to convey ideas to other team members, or to show a bug in action.

     

    Easily filter tasks

    By default, JIRA has two filters set up that allow you to show only issues assigned to your, or recently updated issues. But you can easily create custom filters to display only the issues that you want. You can do this using the JIRA Query Language (JQL). This is especially useful when you have a large number of tasks on the board and you only want to show certain ones – doing this on a physical board would be much more difficult.

    filters

     

    Easily create a Wallboard to radiate information

    You can easily create a Wallboard in JIRA that will act as an information radiator. Of course you could also do this with a physical wallboard, but using an electronic board means that the information is automatically refreshed so it’s always up to date.

     

    Better for distributed teams

    One of the largest advantages of JIRA is that it allows distributed teams to easily see an up to date, synchronised board without the need for the Scrum Master to coordinate updating each teams Scrum board.

     

     

    Physical

    More sense of accomplishment when moving a card

    Developers often get more enjoyment from moving a piece of card on a board than from dragging and dropping in an online system. Perhaps it’s because it allows them to step away from the computer for a while or just because of the tactile action it involves.

     

    More visible to those outside of the teamvisible

    A physical board is immediately accessible by anyone who visits the location it’s kept. They don’t need to know an URL, or login to a system in order to view the status of the Sprint. An electronic board can mitigate these issues by utilising a wallboard that doesn’t require a login and can be displayed in the same way a physical board would.

     

     

    Simpler interface

    The interface of a physical board is often kept quite simple. This may be partly due to the fact that there simply isn’t space to include comments, labels, etc, like you can on JIRA. But how many of JIRA’s issue properties do you actually use and how many add unnecessary complexity?

     

    Conclusion

    One of the arguments against electronic board such as JIRA, are that they don’t get updated, possibly because they’re not as accessible as a physical board. But an electronic board can still be made as accessible as a physical board. Simply display the board on a large screen/projector, in the same location you’d have your physical board. If you’re able to utilise a touch screen, team members can physically drag and drop tasks, similar to what they’d do on a physical board.

    But at the end of the day the correct approach is to do what works best for your team. Use the empirical approach of Scrum to try new things – perhaps for the next Sprint you can try using a physical board and see how it works. Or if you’re already doing that, give JIRA or one of the alternatives a try.

    Scrum Artifacts and how to ensure transparency

    Let’s look at the Artifacts involved in Scrum – items or objects that provide Transparency and allow us opportunities for Inspection and Adaptation.

    Product Backlog

    The Product Backlog is an ordered list of all the features that might be required in a product. The Product Owner is responsible for the content, ordering and availability of the backlog.

    The Product Backlog is a living artifact, that is, it is never complete. Items are removed from the backlog when they are selected for a Sprint. Items can be added to the backlog at any time, but are most commonly added during Backlog Refinement.
    Initially the backlog holds only the best known requirements, but as the product and its environment change, items are added to the backlog.

    The items in the Product Backlog are ordered by their priority. Higher ordered backlog items are usually clearer and better understood than items lower down the list. As items increase in priority, they are refined so that the Development Team have a better understanding of them.

    The Product Backlog is an information radiator – a large, easy to see, display of data that is accessible to all. It allows individuals to see the upcoming features for a product and liaise with the Product Owner if they think an important requirement is missing. However, only the Product Owner can add items to the backlog.

     

    Sprint Backlog

    The Sprint Backlog consists of the Product Backlog Items selected for the Sprint, plus a plan of how to turn those items into an Increment.

    During Sprint Planning, the Development Team decides which items it can implement during the Sprint, and these items are selected for the Sprint Backlog. The Development Team then formulates a plan on how to complete the work.

    sprint backlog

    As more information becomes available during the Sprint, the Sprint Backlog may change, with new items being added or unneeded items being removed. The plan to implement the items may also change.

    The Sprint Backlog is owned by the Development Team. Only they can decide how much work can be completed in a Sprint and only they can change the Sprint Backlog.

     

    Increment

    The Increment is all the Product Backlog Items that have been completed during the current Sprint, plus all of the previous Increments. The Increment is a “Done” piece of software functionality that is potentially releasable to the customer. It is the decision of the Product Owner if the Increment is actually released or not. The Increment should allow the Sprint Goal to be satisfied.

     

    Artifact Transparency

    So that artifacts can be inspected, they must be transparent. This allows decisions based on the state of the artifacts to be made in order to control risk and increase business value. If artifacts are not sufficiently transparent, then they cannot be successfully inspected and risks may increase, costs may rise and decisions can be made incorrectly.

    A good level of transparency has been achieved when the state of an artifact allows it to be easily inspected. This can be achieved by creating an open and blameless culture and ensuring that all members of the Scrum team are easily accessible. Stakeholders should be able to easily visit the Development Team in their office, as long as this doesn’t negatively affect the work of the team e.g. by stakeholders trying to add work to the Sprint without the consent of the Product Owner.

    The Scrum Master works to ensure that all artifacts have the required level of transparency. They can do this by inspecting the artifacts, looking for patterns and noting differences between expected and actual results. For example, a Cumulative Flow Diagram can show where backlog items have been stuck in progress, causing a bottleneck. However, if a Scrum Master is made aware of an impediment, but this isn’t reflected in the cumulative flow diagram, this can indicate that the progress of a backlog item hasn’t been updated i.e. the Sprint Backlog doesn’t have full transparency.

    Alhmodeus / CC-BY-SA-3.0

     

    Scrum Events – Backlog Refinement

    Backlog Refinement isn’t an official meeting as defined in the Scrum Guide, although it does state

    The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.

    The meeting is held mid-Sprint, before Sprint Planning and the aim is to get the Product Backlog and its items into such a state that the highest priority items can be pulled into a Sprint. It ensures that the Sprint Planning is effective and efficient – team members can focus on selecting the PBIs for the Sprint, rather than trying to understand the PBIs.

     

    The aim is to prioritise the Product Backlog so the items with highest priority are at the top and ready to be selected. Backlog Refinement also ensures that PBIs are of a good quality and are understood by the team. Ideally we want to conduct enough refinement so that we have PBIs to cover the next two Sprints. This ensures that even if the Product Owner is unavailable, or the Development Team has extra capacity, there are enough PBIs in a ready state.

    Below are the steps that take place in the Backlog Refinement meeting:

    product owner

    Prioritise

    Coming into the refinement meeting, the Product Owner should already have a good idea of which PBIs are the highest priority. Outside of the Scrum meetings they will meet with stakeholders in order to prioritise the backlog. They can use a variety of prioritisation techniques to achieve this, with assistance from the Scrum Master.

     

    Understand

    The Development Team must understand the PBIs so that they can successfully implement them. This can take the form of querying the Product Owner or the stakeholders. It may also require the team to go away and research a particular topic in order to improve their understanding of it. This research time should be included as part of the 10% Backlog Refinement time, to ensure that it doesn’t take over the time needed for development. Research tasks shouldn’t be added to the current Sprint, as they’re not adding any business value.

     

    INVEST/refine

    Once the team has an understanding of what a PBI requires, they must ensure it’s of a good quality by using INVEST. This ensures that an item is Independent, Negotiable, Valuable, Estimable, Small and Testable.

    If the item doesn’t meet all of these criteria then it must be refined so that it does. This involves splitting the item into thin vertical slices that cover each of the architectural layers i.e. database, server, client.vertical slice

    Each slice covers a level of functionality right through from the front-end to the back end. It might only offer one particular feature, but that feature is completely throughout each level of the architecture. Importantly, a vertical slice allows us to deliver something of business value.

     

    Acceptance Criteria

    Once a PBI is appropriately sized and understood, the team define acceptance criteria for it. This allows them to define when an item is Done.

     

    planning poker

    Estimate

     

    Bearing all of the above in mind, the Development Team can now estimate each of the PBIs that we’ve been dealing with (2 Sprints worth). There are a few methods for doing this, which you can read about in my post Estimating Product Backlog Items.

     

    You may find that once estimation has taken place, the Product Owner revises his prioritisation of the items. That ‘must have’ feature might not be so important when he discovers how much effort is required to complete it.

     

    Conclusion

    The Backlog Grooming meeting ensures your backlog is ready to go when it’s time for Sprint Planning. Done correctly the output will be a prioritised backlog with items that are understood by the team, of an adequate size and estimated. This means the Development team can more accurately select the appropriate number of items for their Sprint Backlog. This in turn means they should have a consistent Velocity, which leads to more accurate forecasting.

    Scrum Events – The Sprint Retrospective

    The Sprint Retrospective allows the team to inspect itself and adapt the Scrum process for the next Sprint. The meeting is time-boxed to 3 hours and involves the whole Scrum team.

    We look at how the last Sprint performed with regard to

    • People
    • Processes
    • Relationships
    • Tools

    We also identify what went well and what could be improved. This items can also be ordered in terms of importance.

    Finally, the whole team collaborates to create a plan for the next Sprint. This details how the improvements that have been identified, will actually be implemented.

     

    The role of the Scrum Master is to see how the Scrum process can be improved so that the team can fully benefit from it. They encourage the team to improve their development processes so that they are more effective in the next Sprint.

    Using what we have learnt from the Sprint Review and Retrospective meetings, the team can adapt the Definition of Done. For example, perhaps a stakeholder who turned up to the Sprint Review was colour blind and the team had not tested for sufficient contract on text colours. The Definition of Done can be adapted to the include accessibility testing of the subsequent increment.

     

    Although it is one of the shortest Scrum meetings, it is also one of the most important. It allows us to utilise the empiricism that Scrum offers, so every Sprint we have a formal opportunity to inspect and adapt.

    In subsequent posts, we’ll look at some of the techniques that can be used during the Sprint Retrospective in order to facilitate discussion and learning.

    Sprint Retrospective technique – Stop, Start and Continue

    Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.

     

    start stop continue

    Start, Stop and Continue

    In this technique, team members describe actions they think the team should Start, Stop and Continue doing.

    Start items are those that the team haven’t done before but it seems likely they will be of benefit.
    For example:

    • Show the software to the customer before the Sprint Review.
    • Ensure everyone has an equal amount of time to speak at the Daily Scrum meeting.
    • Include research time in PBI estimation.

     

    Stop items are those which don’t add value or are inefficient.

    • Stop trying to use the latest, in fashion Javascript framework.
    • Don’t work on items that aren’t on the Sprint Backlog.

     

    Continue items are those which we think have benefits, but haven’t yet become habit. Including them on the continue list gives us a reminder and ensure we do them in every Sprint.
    Any of the previously identified Start/Stop items can go onto the Continue list. They are removed after a few Sprints, to ensure the list doesn’t get too long.

     

    Selecting items

    There are many ways in which the Scrum Master can ask for suggested items.

    • Simply allow team members to shout out the items.
    • Only allow particular items e.g. the Stop items.
    • Go round the team to ensure that everyone has the chance to put forward their ideas.

     

    Voting

    Once enough ideas are generated, the team should vote to determine which are the most important. This can take the form of each person voting for their highest priority item, or being allowed a certain number of vote e.g. 3, that they can assign to items as they wish.

     

    The Subsequent Sprint Retrospective

    At the next Retrospective it can be useful to bring along the list of items. The team can then determine if they have been effective in starting, stopping or continuing the items that were given the highest priority.

     

    Conclusion

    The Start, Stop and Continue technique is an easy way to generate actions during a Retrospective. It’s easy to grasp and you don’t need any special tools or software (although a physical board for displaying items on is helpful).

    Sprint Retrospective technique – The Sailboat

    Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.

    sailboat

    This technique uses a sailing boat as a metaphor for the team. The wind represents the things that are pushing the team forward, while anchors represent the things that are holding it back.

    Using a diagram of the boat, team members use post-it notes to detail items in each of the above categories. They then stick them to the diagram in the appropriate place and read it out as they do so. You may find that common themes emerge, so related notes can be grouped together.

    Once all the notes are posted, the team may choose to dot vote on those they think are most important. Usually each member has around 3 votes, which they can distribute however they wish.

    The team then looks at the items under each heading. The ‘wind’ items are those that the team should continue doing. While the ‘anchor’ items should be addressed to remove the impediments. Perhaps ‘anchor’ items can even be transformed into ‘wind’ items?

     

    Going forward

    You don’t have to stick with the sailboat metaphor, there are many other objects you could use – cars, hot air balloons, a tree.

    Sprint Retrospective technique – Timeline

    Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.

     

    A timeline retrospective allows the team to inspect how well the Sprint went, over a period of time. First, you will need a set of axes that represent each day of the Sprint. If you imagine the diagram below, but without the coloured cards.

    Adding cards

    Each team member will have cards in the colours above and they write down the events that occurred, on the appropriately coloured card. They then attach the card to the board so that it corresponds to the time that it occurred during the Sprint.

     

    Drawing Conclusions

    The chart provides an excellent visual representation of the Sprint and allows the team to easily see what went well and what could be improved. It also allows us to discover if certain events lead to other events – perhaps a significant event lead to a series of problematic events. Or there may be a cluster of good events around a particular time period.

    Either way, the team can discussed these points and learn from them.

    This chart could also be compared to the burndown chart for the Sprint. Does the velocity of the team increase when it experiences good events?

     

    Actions

    Based on the discussion, the team should identify actions they can take in order to improve in the next Sprint.