"As a user of your system, I want functionality so that I can achieve my goals. Unfortunately, your team's users stories are getting in the way."

Users Stories, the tool teams use to break ideas into small chunks of deliverable work, are easy to describe and challenging to write. This session is about writing great user stories and acceptance criteria by ensuring everyone on the team knows what needs to be done. We will discuss what elements should be included and which ones are optional; why the size of your user story is important and how to make them smaller; and the structure for better acceptance criteria.

You often hear people ask, "Does the ScrumMaster role need to be a full-time role?". Obviously, the answer is yes. And you can point to results that you should expect to see from teams served by full-time, dedicated ScrumMasters. And you can detail the different aspects of the role that require such dedication. But the root of the issue is a misunderstanding of the ScrumMaster role.

One the surface, the ScrumMaster role is relatively simple; to serve the team by removing obstacles, facilitating meetings and coaching. Dig deeper, and the role becomes far more nuanced. The ScrumMaster role is one of nurture and change.

This session analyzes the ScrumMaster role through the lens of choice as an outcome. That is, that the role of the ScrumMaster is to facilitate the choice of an individual to be agile. The role of the ScrumMaster is to enable the behaviors that lead to agility, within the team and the organization.

Scrum is by far the dominant Agile methodology and has been put to good use to positively change many software development groups. Some have found that even when they follow all the Scrum practices, they are still having some challenges, and they have turned to Kanban for help. Kanban is often framed as an alternative to Scrum, but it need not be so. Organizations using Scrum can augment their process with the Kanban Method to become more agile and delivery-oriented.

Jonathan Hansen will use real-world examples, both from product and consulting companies, to show you some of the ways Kanban can work together with Scrum to help you manage the work inside Sprints, manage work that doesn’t fit in Sprints well, and provide a means to continuously improve your work.

If you’re practicing scrum, you’re probably well versed in velocity, escaped defects and other common scrum metrics.  This presentation starts with a review of essential scrum metrics, how to properly use them, and how to interpret their trends.  We’ll then quickly pivot into advanced and emerging metrics that many scrum teams (and programs) have found beneficial - examples include: how to measure and quantify the cost of delay when your team is blocked, how to ensure your team is investing the right amount of time to maintain clean code and create automated test scripts, and how to assess that your team is sharing work to support the whole-team approach.  We’ll review a comprehensive taxonomy of scrum metrics and show examples of presented metrics in use.  We’ll conclude talking about opportunities to better empower scrum teams to self manage by integrating economic and budgetary data with scrum metrics - consider this example: rather than reviewing estimates & actuals for all the stories completed in a sprint, determine your team run rate and track the cycle time for each story completed, then use these two data points to compute the cost for each story completed during a sprint, finally ask yourself if your customer or sponsor would be happy with the amount they invested to complete each story - if you’ve never tried this type of economic analysis with your team, trust me, you’ll have a much different (and probably more effective) discussion.  By attending this session, participants will learn a comprehensive list of metrics and practices to gain greater insights to team / project health and reduce delivery risk - participants attending will receive a metrics worksheet that will list all metrics presented and include why and how to track each of them.

Everyone knows that scrum works best when the entire team is sitting together in the same office. But the reality of today's working world is that more and more teams are geographically distributed. In many cases, this is the result of "strategic priorities" from senior management and is entirely inflexible. As scrum practioners, we must come up with strategies for adapting scrum to a distributed world. This talk will take a hypothetical distributed scrum team from release planning all the way through to launch day. What are some of the problems that will come up? What are the best ways of overcoming these issues? How should Scrum Masters facilitate sprint planning, sprint reviews, and sprint retrospectives? 

In every job that must be done,
There is an element of fun.
You find the fun and snap!
The job's a game.

- From "A Spoonful of Sugar", Mary Poppins

As an Agile Coach, I use games to demonstrate concepts to teams. Games take otherwise theoretical ideas and help teams feel them in their bones. Once they've gone through a demonstration, the air is ripe for further exploration through conversation.  Sometimes, though, you don't have the right game for the particular problem you are trying to address.  Fortunately, as Mary Poppins points out, there is fun in every job...it's just a matter of finding it. We all have experience making our own work fun, and I think that's what puts creating games in everyone's reach.  In this workshop, I'll share how I've gone about building games, and each participant will have a chance to build their own.

Note: I am calling this workshop a spoonful of sugar, not a bowlful.  While I love using longer games/workshops (like Alistair Cockburn's brilliant Elephant Carpaccio), I just can't grab the team for two-hour chunks of time all that often.  In this workshop, we'll focus on much shorter games that you can sneak in during a slow day, or in that hopeful moment just after sprint planning is completed.  These smaller games tend to isolate much simpler, smaller concepts.  I believe that a steady diet of these easy-to-digest games really helps teams incorporate the concepts in their daily work.

Most practitioners agree that co-location makes a more efficient agile team. Over the years, I’ve worked with teams that are co-located as well as teams with members in multiple locations.  I've observed many ways to make the distribution somewhat less painful, and to reduce the impacts. There are many great tools out there to better enable collaboration across geography, and hundreds - maybe thousands - of viable communication tools as well.  

None of these can give you the equivalent of turning around in your chair and tapping your colleague on the shoulder to ask a question.  It's those informal communications that can make a co-located team more efficient.  I’m seeing more and more enterprises bringing development teams back together physically, reducing and even eliminating the dispersion of their teams.  

Fortunately or unfortunately, depending on your perspective, flexible workplace arrangements are more and more commonplace. Even if your team is co-located on paper, there will be times when team members may not be in the same location. And then there are times when teams are dispersed due to emergencies or weather conditions. Here in the northeast US, we are experiencing an high number of disruptive storms this winter.  Even agile teams that are usually co-located find themselves working in a widely dispersed fashion – whether they expect to be or not! 

So, even if you have a 100% co-located agile team, you need a plan to deal with and be successful with your team members distributed in multiple environments.  In this session, I will discuss some basic tips and techniques for you to consider as you formulate your game plan.