Blog

Over the years, I’ve been asked multiple times what a Nexus Sprint Review might look like. I’ve not been satisfied with the guidance I’ve found online regarding Nexus Sprint Review, so I decided to finally write my own." Please feel free to adopt any ideas from this post and run your own experiments. Also, if you are not using the Nexus Scaled Scrum Framework, that’s fine. Just know that in this blog post, when I refer to Nexus Sprint Review, you can think scaled Sprint Review.

I was teaching our new SSDT2019 class today and, while discussing SQL Server Unit Testing, I was asked why the default Row Count test condition only tested for equality (and not less than, greater than, or inequality). I decided to build one that did just those things.

First, I dusted off the old guidance from (cough) 2012 and was amazed that the guidance still mostly applied. Using Visual Studio 2019, I created a new C# Class Library (.NET Framework) project named CustomTestConditions. I generated and associated a strong name key and then referenced System.ComponentModel.Composition and the Microsoft.Data.Tools.Schema.Sql.dll assembly.

I'm feeling encouraged. It seems that more and more teams, whether they are using automated or manual tests, are using Azure Test Plans to create and track their acceptance testing efforts. I was teaching a pre-conference workshop at STARWEST last week, and a student asked how to find all the Product Backlog Items (PBIs) in the current Sprint that *didn't* have any associated Test Cases. If a team is using Bug work items, they could be included as well.

Product Backlogs are boring. Not only are they one dimensional, but they are often unordered. This is to say nothing of their potential lack of information as well. (User) story maps are way more interesting. Not only are they two dimensional, but they group features and ideas and help to visualize the release plan. Also, teams that practice story mapping tend to be more Agile, with engaged Product Owners and stakeholders. SpecMap is a great story mapping Azure Boards extension by the way.

At the beginning of a Sprint, the Product Owner presents a refined and ordered Product Backlog to the Developers. A Sprint Goal is crafted and the Developers select an achievable set of the items to achieve the Sprint Goal best. This is their forecast. The Developers also create a plan to achieve the Sprint Goal by developing the forecasted items. All of this goes into the Sprint Backlog.

The Developers proceed to work to achieve the Sprint Goal, assessing their progress and updating their plan at least daily in a short meeting known as the Daily Scrum. The Scrum Master helps the entire Scrum Team follow the rules of Scrum and be productive throughout the Sprint, as well as help the organization understand this empirical way of working.

According to the Scrum Guide, the Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. As the Development Team works, it keeps the Sprint Goal in mind. Unfortunately, there is no first class support for Sprint Goals in VSTS. Instead, a team could write it on their whiteboard, use the VSTS Wiki, or add something to a dashboard (in fact there is a widget extension in the marketplace for doing the latter). While these are all working solutions, they don’t necessarily keep the Sprint Goal “in the team’s face” while they plan and execute their work in the Sprint Backlog.

An energizer imparts energy, vitality, or spirit to other people. Energizer activities are important in classroom training environments - especially right after a large lunch. Here is a good list of energizers recently compiled by Jesper Fernström (a fellow trainer from Sweden) …

• Happy Salmon - You can also try playing in groups of 3, 6, and 10+ to experience locking, normal, and chaos respectively
• Longest caterpillar - Everyone moves around in the room. When you meet someone do a quick Rock-Paper-Scissors. The loser stands behind the winner, hands on the winner's shoulders, and loudly chants the winner's name while the winner finds another caterpillar for a new round of Rock-Paper-Scissors. Losing caterpillars attach to the winner and help chant the winner's name. Repeat until there is only one caterpillar. Feel free to keep chanting for a while for good measure.
• Chairs - Split into three groups. Give each group a secret mission (turn chairs upside down, stack chairs, and put chairs in a circle). Without talking, teams start fulfilling their mission. See if they can find a way to fulfill all 3 goals.
• Non Musical chairs
• Connecting people - One person starts telling facts about himself, like "I have a dog", "I play tennis", and so on. As soon as someone else hears something that connects them they physically connect with hooked arms. The newly connected person starts calling out facts until the next person connects. Repeat until all are connected.
• Introduction circle - Stand in a circle facing each other. One person takes a step forward and tells everyone one thing about herself, like "I have a dog". Everyone who fits that statement takes a step forward. Reset and repeat as many times as you like.
• Stop them - 5 people facing a single person from a few feet away. The 5 starts moving towards the single person who is not allowed to leave his spot and must now stop them from walking into him using voice, body language, and facial expressions only. They will only stop when they feel there is a genuine command to stop. Prepare to have your personal space invaded!
• Making rain
• Silly walk - As in Monty Python. One person leads, and others mimic. Switch leader between every walk.
• Human knot - Even number of people. Every person raises their right hand and takes hold of someone else's raised hand. Then take hold of another person's left hand using the left hand. The human knot has formed. Now try to untangle it without letting go of holding hands. The grip can be loose and flexible, but you cannot let go entirely.
• Helium stick - Give a yardstick/rod (~3 feet long) to a group of 4-6 people. Ask them to estimate how long it will take them as a group to lower the stick to the ground. Have them standing on both sides of the stick balancing it horizontally at chest height using only one extended finger each under the stick. Their goal is to gently lower it to the flow, as a group. Feel free to question their ability to follow instructions when the stick starts to rise ... which it will.

When planning a team-based training event, please consider the room configuration. Having a comfortable table and chair arrangement will go a long ways towards a positive learning experience.

Round or square tables allowing students to sit in teams of 4-6 with laptops is ideal. Include wall space for plenty of whiteboards, flip charts, and sticky notes. Even for training that is not specifically team-based, pairing is still encouraged. This means there only needs to be one laptop for every two students.

As a traveling Scrum and DevOps consultant I’m constantly asked “Should our team use Scrum”? Now you might think that being a Professional Scrum Trainer – and serious Scrum fanboy – I would always answer “Yes!”. Well, you would be wrong. I frequently talk people out of Scrum – for the right reasons.

Professional Scrum Trainers know how hard it is for a team, not to mention an organization, to adopt and practice Scrum according to the Scrum Guide. Therefore, we want to make sure the teams and nature of the work are right for the Scrum. To that end, I’ve come up with five simple, mostly non-scientific, yes/no questions that I use to survey the inquisitor.