Jeremy Jarrell

Agile Made Simple

Category: Uncategorized

Help! My Team Keeps Missing Releases

Lately, I’ve seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If…

Lately, I've seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If you were to plot the team's hit rate, or number of points completed over those forecasted, then you would see a fairly straight line at 100%.  The plot below represents a team who, after an erratic first few sprints, has settled down to a particular 100% hit rate.

Hit Rate From the outside, it looks like the team is right on track.  But, as they begin to near the end of the release, everyone starts to realize that the picture isn't quite as rosy as first thought.  In fact, it becomes obvious that they're not on track at all to complete all planned work in time for the release, even though they had consistently completed the same number of points they had forecasted.  How does this happen?

Finding the Churn

This can occur when the team regularly accepts new work during the sprint that pushes the planned work to the side.  This work, which often takes the form of high priority bugs or customer issues in production that must be fixed immediately, is estimated and added to the sprint alongside the existing work.  Often, this “high priority” work pushes the previously scheduled work to the side.  At the end of the sprint the team celebrates completing the right number of points…unaware that they actually completed the wrong points.

How can we catch this before we near the end of the release so we can do something about it?  By tracking “point churn”.  Churn is the number of points added to a sprint after it has begun.  Typically, we discourage adding work to an in progress sprint but some teams follow this practice to handle high priority work that must be addressed quickly.  These teams can get early insight into their churn by plotting the number of points added to their sprint alongside their hit rate.

Hit Rate with Point ChurnThe plot to the right adds an additional line along side hit rate to indicate point churn.  The red line, bound to the right axis, represents the number of unplanned points added each sprint.  You can see that although the team maintains its 100% hit rate, more and more points have been added each sprint.  This could be an indicator that although the team is completing the right number of points each sprint…they could actually be completing the wrong points.

If you notice that your hit rate is consistently around 100% but your churn is regularly above 0 then this is can be an indicator that you're falling behind in your overall release, even though you're completing the planned number of points each sprint.

A Simpler Approach

But there is another approach.  Rather than go to the effort to track unplanned work that is added to each sprint, an alternative approach is for the team to still accept the unplanned work but not award any points to it.  In this model the work is not added to the sprint, but it is still tackled alongside sprint work.  This approach is easier since it doesn't require tracking additional points and, if the team reaches the end of the sprint and still has planned work outstanding as a result of being distracted by the unplanned work, then the hit rate for the sprint actually provides a more accurate reflection of how the team is likely to pace for the overall release.

To make new work more visible in this approach you can even add an additional lane to your sprint board for it to flow through.  Seeing this work alongside your planned work, especially with team members assigned to it and Work in Progress limits respected, is a wonderfully effective way to illustrate the impact that new additions can have on your sprint plan.

Scrum Board with Firelane

In the image above, we've added an empty row to the bottom of the standard scrum board to allow unplanned work to flow across the board.  These cards are red to indicate their importance.  However, note the WIP limits for each state called out in parenthesis at the top.  Deploying has a WIP limit of 1 meaning, that the unplanned work is currently blocking release of the planned work for the sprint.  Adding an explicit lane to the scrum board can more visibly call out the effect that unplanned work has on a team's productivity rather than the team simply accepting the work but then quietly falling behind.

Whichever approach you choose, asking whether your team is completing the right points instead of just all of the points can provide early insight into your team's pace and give you the opportunity to correct your course before its too late.

Are you new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Help! My Team Keeps Missing Releases

Release Planning from the Top Down

Quick…what was the killer feature in your last big release?  If your release is like most then you’ll probably have trouble answering that question.  In fact, if your release is like most…

Quick…what was the killer feature in your last big release?  If your release is like most then you'll probably have trouble answering that question.  In fact, if your release is like most it was probably filled with a grab bag of low quality features and a handful of bug fixes.  Sure, there may have been one or two important features in there, but for the most part they were buried amongst an avalanche of noise.

Bottom-Up Release Planning

Bottom Up Release PlanningWe call this type of release planning Bottom Up Release Planning.  It often begins with simply combing the backlog for stories that need to be released and grabbing as many as you can fit in your next release.

Sure, there are advantages to this, most notably that it's easy to do.  Release planning tends to be simpler and take less time using this method.  In fact, you've probably seen these types of releases before, they often begin with a “wishlist” of features that absolutely must be in the next release.

But releases planned in this way tend to feel disjointed and often fail to make an impact on your users since there's nothing tangible for them to bite on to.

Top-Down Release Planning

Top Down Release PlanningThere's a better way…and we call it Top Down Release Planning.  This type of release planning occurs when we first define an objective or goal for each release and then select only those backlog items that fit that objective.

This type of release planning can be a bit more involved since we must decide if each item selected fits the objective of the release, but it can lead to much more cohesive releases.  These types of releases often make a bigger impact on users which can resonate with them for a long time to come.

Why Bother?

You may be wondering why if Top-Down Release Planning is even a little more difficult then why we put forth the extra effort?  Well, aside from the advantages I mentioned already, highly cohesive releases tend to be much easier to build a memorable marketing message around.

In addition, focusing the release on a key objective also allows us to make greater strides in trying to solve a sticky problem that our users are currently facing.  If we can solve a particular pain point—and build a great message around that solution—then we're much more likely to deliver a release that will resonate with our users.

Want to Know More?

I cover Top-Down Release Planning in more depth in my course new course Agile Release Planning, available on Front Row Agile.  If you've ever struggled with building large-scale projects using agile techniques, or have just wondered how planning works in an agile framework then this course is a great fit.

In addition to Top-Down Release Planning I also cover

  • How traditional planning and agile planning differ, and how to start adopting a more agile mindset.
  • How to develop a vision for your projects, including creating a vision board and learning proven techniques to cultivate focused concepts.
  • Strategies for building a roadmap to your goal and important things to consider in the first release and all future releases.
  • Ways to plan the release, including how to develop a release grid and prioritize features well.
  • How to build the product backlog by looking through the lens of DEEP and constructing effective sprint plans now and far into the future of your agile development.
  • Methods to keep plans on track when things just don’t go as you expect.

This course is regularly $50 but for a limited time readers of this blog can get all of this content for just $40 by using the discount code PLANBETTER at checkout.  That's an additional 20% off just for following this blog.

Just enter the code above to claim your discount and be on your way to planning great releases and I'll see you in the course!

Comments Off on Release Planning from the Top Down

Where Afternoon Standups Go Wrong

Most teams are familiar with the morning standup, or the classic scrum ritual that gives teams the opportunity to sync up and plan their work for the day.  For many…

Most teams are familiar with the morning standup, or the classic scrum ritual that gives teams the opportunity to sync up and plan their work for the day.  For many teams, the morning standup is the bread and butter of their scrum process.

But every once in a awhile a team tries to move their standup to the afternoon.  The reasons always sound legitimate:

“Not everyone gets here at the same time, so we'll just hold our standup in the afternoon.  That way everyone can attend.”

or

“Mornings are when we're most productive…we don't want to interrupt that with another meeting.  Let's just have the standup in the afternoon.”

As valid as these reasons sound afternoon standups have a tendency to be less useful than morning standups, but the reasons why aren't always clear.  Let's take a look at why.

The Ritual Suffers

Morning standups create a nice ritual for your team.  Everyone trickles by 9 o'clock, checks their email, and gets their morning cup of joe.  But, at 9:30 everyone filters into the team room and it's time for the standup.  After a quick standup the team starts their day for real.  The 9:30 standup is the signal for the day to start.

On the other hand, even though afternoon standups are still scheduled at the same time every they are much less likely to start at the same time every day.  This is because by the afternoon the day is much more likely to have gone awry.  Maybe tasks have taken longer than expected so not everyone is ready.  Perhaps a fire has much of the team too distracted to make the original time.  Or, even if all of the team is available, maybe other meetings outside of the team have ran long and the team's normal meeting space isn't available.  Now the team has to hustle to find a space that can accommodate them for their already late standup.

Standups Last Longer

No one likes a long standup.  In fact, one of the most common complaints from new scrum teams is

“Our standups always last at least 45 minutes.”

All standups are susceptible to this but afternoon standups are particularly so.

Think of how you feel in the morning:  You're energized for the day, you've had a fresh cup of coffee, and you're ready to tackle that sticky problem from yesterday.

Now, think of how you usually feel in the afternoon:  You've just had lunch.  You've already been at work for 5 hours, and all you want is a reason to sit down and take a break for a bit.  The afternoon standup is that reason.

And, once everyone has sat down, the standup begins to drag.

Your New Status Meeting

But, the most insidious problem of all with afternoon standups is much more subtle.

Standups should have two goals…

  1. Identify blockers so they can be brought to light and removed.
  2. Allow the team to sync up and plan their work for the day.

Nowhere in that list is a goal for the team to report the status of their current work in progress.  That's not the purpose of the standup…that's the purpose of the scrum board.

Morning standups are very conducive to these goals since they encourage the team to identify blockers early in the day and to synchronize the day's work before they get started on the wrong path.

But afternoon standups share neither of these traits.  Although the same blockers might exist in the afternoon as they did in the morning, team members are less likely to bring them to light since they may mistakenly believe they're close to solving them.  Even if they do, the other team members are likely too deep into their own tasks to volunteer much help.  In addition, since the individual team members have already started their work for the day there's no opportunity to synchronize the work as a team…everything has already begun.

With both of these options off of the table only one thing is left to talk about in an afternoon standup…status.  When held in the afternoon the focus of the standup naturally shifts to what each team member has accomplished so far that day.  Rather than providing the opportunity for the team to clear their own way and plan the day's work ahead, the standup simply devolves into yet another status meeting.

Try It and See

The differences between afternoon and morning standups are subtle but the results can vary dramatically.  If your team is currently using afternoon standups and something just doesn't feel quite right then give morning standups a try.  The difference may surprise you.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Where Afternoon Standups Go Wrong

Splitting User Stories Across Teams

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here. Sometimes large…

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here.

Sometimes large user stories are broken down into smaller stories that are tackled by multiple teams.  For example, imagine that your organization has two teams: a team that owns your web application and a team that owns your mobile application.  If you are releasing a feature across both platforms you may originally start with that feature described as a single user story but then split the story in two as each team tackles their respective implementations.

When multiple teams work on a single product we like to keep a single Product Backlog that all teams share. This lets the Product Owner see the big picture at any given time which helps keep them focused on the overall vision for the product.

Even if a larger story that will ultimately be split across several teams we tend to keep it as a single story during the Product Backlog phase.  This helps to prevent us from getting mired in the weeds of each story too early and makes the story easier to move up and down the backlog as new priorities emerge.

Product Backlog

Keeping the story as a single unit also it makes it easier to assign an estimate to.  Admittedly, we know that the estimate won't be as accurate as if we broke the story down and estimated each individual part, but that's ok.  We accept that estimates are less reliable during this stage and only use them for getting an idea of the complexity of a story relative to other stories in the backlog.

Splitting User Stories During Sprint Planning

However, during Sprint Planning the top stories in the product backlog are moved into a separate Sprint Backlog for each team. At this point those same large stories are broken down and split into separate stories for each team, who then take this opportunity to estimate their individual portions. The sum of those estimates may add back up to match the original estimate of the large story, but don't be surprised if they don't.  Breaking larger stories down into smaller stories often tends to expose gaps that we didn't originally consider when the story was in its larger form, so new stories may emerge as a result.

Product to Sprint Backlog

Allowing each team to work from their own Sprint Backlog minimizes the number of dependencies each team needs to complete their work.  We want each team to have as many of the skills as possible to complete a valuable increment of the product during each sprint, which is one of the reasons why we strive to make scrum teams cross-functional.  If a team can still deliver a valuable increment themselves, then we want that work split only into the portion that they can complete.

In addition, Velocity is our primary planning metric in scrum.  Teams who estimate in story points eventually start to evolve those points to the range that makes the most sense for each team.  Put another way, a story point for one team may be wildly different than a story point for another team.  This flexibility is what gives story points their power as each team starts to assign the most accurate value to each point that makes sense to them.

The side effect of this, however, is that the Velocity of two different teams can start to vary wildly even if each team is completing roughly the same amount of work.  For this reason we want to be able to map a separately velocity to each team which better represents the amount of work they're completing during a sprint rather than trying to roll all velocities into a single number.  This gives us a more accurate representation of how much each team tends to complete during each sprint, which lets us plan the overall product even better.

Want to learn even more ways to split your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Splitting User Stories Across Teams

How to Best Slice User Stories

Splitting large stories into smaller stories is one of the best things a team can do to improve their workflow. But how do we split these stories?

Thanks to Ben Godwin for a great email question that prompted this post!  If you have your own questions about agile and don't know where to turn, drop me a line for some free advice.

Learning to split large user stories into smaller user stories is one of the best things a team can do to improve their scrum workflow.  Not only are smaller stories easier to understand and therefore easier to estimate, but their smaller size makes them inherently less risky for a team to take on.

However, when teams first start splitting stories they’re often tempted to split them horizontally rather than vertically.  To understand what I mean by this, let’s take a look at an example.

Imagine that you had a story to allow a salesperson to log into a sales management application.  The story may look something like this…

 “As a salesperson, I would like to log into my sales management application, so I can enter my lead information.”

At first glance this story may look pretty simple.  However, as we start to unpack it we realize there are a few additional concerns here that we may not have thought of originally.  For example, what feedback will we give the user when they enter an incorrect password, or how many times can a user enter an incorrect password before their account is locked?

After these additional concerns have come to light this story may become too large of a story for a team to feel comfortable tackling.  Instead, they may decide to slice it into smaller stories that can be tackled one at a time.

Slicing User Stories Horizontally

In their first attempt at slicing, most teams will try to slice the story horizontally…or across architectural lines.  This might result in new stories that look like this…

  • Create a user interface with a username and password field that shows validation errors when the user enters an incorrect password or locks their account.
  • Implement the server side logic to validate the user's password and to keep track of how many successive incorrect login attempts the user has made.
  • Update the user record in the DB.  For example, update the last login date on a successful login or lock the account if the user makes three incorrect attempts.

Horizontally Sliced User StoriesIn the image on the right, we can imagine that the slice of cake represents the complete story of a salesperson logging into the application.  Each layer of the cake represents a corresponding architectural layer, from the user interface to the database.

Each rectangle overlaid on the image represents one of the story slices from above.  For example, the orange rectangle may represent the story to create the user interface while the yellow rectangle represents the story to implement the database changes.

Slicing stories horizontally is always a nice place for teams to start because it feels familiar to how developers think.  This is because we tend to decompose problems into technical layers.  However, it also mimics the structure of teams that have come from a more traditional environment.  Many teams are used to working in more siloed environments where they're split amongst a database team, a UI team, and a server team each of which is responsible for their own tasks.  Even when we break down the silos and bring those people together as part of a scrum team many of us still tend to decompose the tasks in the same way.

However, as easy as horizontal story slicing is to get started with it’s not without its drawbacks.  The biggest being that it encourages developers to specialize which lowers your bus factor.  It can also lead to the development team avoiding certain stories or leaving them to the end if they demand a skillset that none of the team feels confident with.  For example, if your team is composed entirely of strong server side developers with little experience on the user interface side then the story above about creating a user interface will likely be avoided by most team members.  Since no one on the team is particularly strong in this skill leaving this story until the end of the sprint makes an already risky proposition even riskier.

Slicing User Stories Vertically

The alternative to this is to slice the stories vertically.  This means that each story crosses all boundaries of the architecture but implements only a sliver a functionality each time.

Returning to our login example, if we slice the story vertically the new stories may look like this…

  • Add the ability for a user to login with a correct password.
    Includes adding the username and password fields to the user interface, implementing the happy path server side logic, and updating the last login field on the database record.
  • Prevent the user from logging in with an incorrect password.
    Updates the user interface to provide an incorrect password validation message and adds a negative path to the server side logic.
  • Lock the user's account after 3 incorrect attempts.
    Updates the user interface to provide a locked account validation message, tracks the number of failed logins either on the server side or in the database, and updates the database record to be locked.

Vertically Sliced User Stories

Returning to our cake analogy from before, we now overlay each rectangle vertically so each rectangle represents a story sliced vertically through the entire architecture.  For example, the orange rectangle may represent the story allowing the user to login with a correct password while the light yellow rectangle may represent the story which locks the account after 3 incorrect attempts.

The advantage to slicing our stories vertically is that each resulting story still provides some sort of meaningful value to the user.  This not only makes them easier to test, but they also become easier for the customer to interact with to provide feedback and guidance for our next sprint.  A customer can provide direction based on their experience with a partially completed login form, but they can’t with only a set of database tables.

Along these same lines, vertically sliced stories also tend to ease the pain when not we’re not able to complete all stories we planned on during a sprint.  In the example above, imagine that we completed the first two stories: allowing the user to login with a correct password but preventing them from doing so with an incorrect password.  However, we were unable to complete the final story which would lock the user’s account after 3 incorrect attempts.  It will be easy for a customer to understand the portion of the work completed versus the portion that’s not when it’s demoed to them.  This would not be the case with horizontally split stories where we had completed the server side logic to validate the user’s password as well as the corresponding database updates, but still had yet to complete the associated UI story.

This Won't Be Easy

Slicing stories vertically is consistently one of the toughest mind shifts for a team new to agile to make.  One reason is that this tends to lead to stories that are more complex and therefore a little tougher to estimate.  It also pushes some developers out of their comfort zone.  For example, if a particular developer is an incredibly strong server side developer but doesn't like to deal with UI issues then they're not going to feel comfortable estimating a story that includes UI work.  In fact, they may not even want to work on it when it comes up in the sprint.

But, if you can get over the initial hump, this technique actually has a lot of advantages.  One of the biggest is that it forces developers to get better at skills they may have been able to avoid in the past, which raises your bus factor.  For example, you're no longer in as much trouble if the “user interface guy” suddenly gets the flu the week before a big deadline.

Another advantage is that it teaches developers to think of features holistically rather than just in architectural slices.  The result is that while at the beginning the estimates may suffer, as the team gets better at thinking about each feature as a whole you'll start to get more accurate estimates over the long run since the team has a greater appreciation for a new feature's impact across the entire system.

Finally, delivering stories which slice through all layers of the architecture tends to make them more complete and therefore easier to test.  This means that you can get feedback on your features even sooner which, in the end, is the real goal.

Are you looking for a Scrum Master for your team? Check out my Scrum Master Assessment on Kand.io, the leading tech-talent assessment platform. This assessment will help you find the perfect Scrum Master to help your team get to the next level.

Comments Off on How to Best Slice User Stories

Choosing the Best Scrum Master

Choosing the best Scrum Master for your team is an important decision. But how do you know who is the best fit? Luckily there’s a way.

Thanks to Kim Hardy for a great conversation which was the original inspiration for this post.  See more of Kim's great work here.

When teams are first adopting scrum one the first questions they ask is “Who should be our Scrum Master.

Often teams take the path of least resistance saying things like “Steve is the Tech Lead, he can do it” or “Joe wants to try it…let's let him do it”.  But choosing a Scrum Master is not something that should be taken lightly.

The Scrum Master is responsible for shepherding the Scrum process for a team.  Not only are they responsible for the execution of the process, i.e., setting up Daily Standups or running Sprint Planning meetings, but they are also responsible for helping the team stick to the process when things get tough.  This means that this is a very important role for the team…especially a new team.

A Mix of Skills

When I talk with managers about choosing their first Scrum Master, I inevitably draw the same diagram on the whiteboard…

Scrum Master Skills

On the left side of the diagram we see a few individuals who really want to try the role of Scrum Master.  Perhaps they have aspirations to management and see the role as a first step, or the adoption of Scrum is new and exciting and they want to be a part of it.  Whatever the reason, they want to be a Scrum Master.

On the other side of the diagram we see those individuals who just seem to have a natural knack for what the Scrum Master role requires.  They enjoy seeing the team succeed as a whole and want to do everything they can to help them do so.  They have the political savvy in the organization to head off outside interruptions so the team doesn't lose focus.  And, most importantly, the team respects them.  These are the individuals that when they speak, the rest of the team looks up from their laptops to listen. These are the exact kind of people that you want facilitating the Scrum process.

If we're lucky, we'll have both types of individuals on a team.  But, if we're really lucky, we'll have that rare individual that falls into both groups:  someone who wants to be a Scrum Master and has the knack to be successful at it.

Those who want to serve this role but do not have the natural ability may not be effective, especially in that tumultuous time when a team is just getting started.  On the other hand, those who have innate ability but aren't truly interested in being a Scrum Master won't give the role the attention that it needs, causing the process to falter as it tries to take hold.

How to Choose

While we'd love to find and individual who has both the desire and the natural ability, the reality of the situation is that few will have both.  Instead, we're forced to choose.  Do we choose the individual who wants to be a Scrum Master but does not yet have the skills, or do we choose the individual with an innate ability but no interest.

When given the option, we should always err on the side of those with want.  If someone has the passion for their new role but is simply lacking skills then, with time, those skills can be taught.  However, if someone has the skills but not the desire, then no amount of time will fill that gap.

Passion Trumps Skill

Choosing the first Scrum Master for your team is a very important decision and not one that should be taken lightly.  Ideally you can find someone with both the desire and natural ability to fill the role, but failing that, someone with the passion and a willingness to learn will always serve the role best in the long term

Want to see more about how to choose the Scrum Master that's right for your team? Check out my course series, Using the Scrum Framework, for tips and techniques for choosing the Scrum Master that's most likely to be successful.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Choosing the Best Scrum Master

Getting the Most out of Your Scrum of Scrums

One of the first hurdles you will run into when scaling beyond a single Scrum team is staying in sync. Luckily there’s a solution: the Scrum of Scrums.

One of the first hurdles that an organization runs into when scaling beyond a single Scrum team is how to keep those teams in sync.  Luckily there's a solution: the Scrum of Scrums.

On the surface, the Scrum of Scrums looks a lot like a regular team Scrum.  In fact, it's even still focused on the same three questions…

  1. What did I do yesterday?
  2. What am I doing today?
  3. What's in my way?

Similarities aside, however, if you want to get the most out of your Scrum of Scrums you'll need a few simple tricks.

Improving the Scrum of ScrumsScrum of Scrums

While a regular team Scrum is intended to coordinate the work that individuals on a single team will tackle for the day, a Scrum of Scrums is intended to coordinate the work for a group of teams.  This difference leads us to a few slight differences in how we can best conduct our Scrum of Scrums.

One Person per Team

As mentioned before, a Scrum of Scrums is intended to be held between groups of teams rather than individuals on a single team.  But rather than ask entire teams to attend this meeting, we instead ask only one individual from each team to attend the Scrum of Scrums on their team's behalf.

Typically this person is the Scrum Master as they tend to have the best overarching view of the team's work.  Also, since Scrum of Scrums are more likely to veer into process-related discussions the Scrum Master is best suited to handle those topics.

Keep Them High Level

Scrum of ScrumsSince Scrum of Scrums are actually held between teams rather than individuals the focus of the meeting is much more on the direction of each team as a whole and how it relates to other teams.  As a result, the updates given by each team's representative tend to be at a much higher level than you may hear in an individual team's Scrum.

A good rule of thumb to know if your updates are occurring at the right level is listen for a good mix of “we” language.  Put another way, are the Scrum of Scrums representatives focusing mainly on the work of each individual on the team or are they rolling up these updates into a broader updates.  Ideally you should hear updates similar to “We're just wrapping up the UI for the new security questions screen and will be moving on to incorporating the security questions in the password reset workflow tomorrow“.  If, instead,  the updates sound more like “Jimmy is putting the finishing touches on the security question screen and Joseph is tying it to the backend code so Sarah can finish testing it.  Then, Jimmy will move on to integrating it into the password reset screenflow so Joseph can incorporate it in the backend” then your updates are too detailed for the Scrum of Scrums venue.

Keeping the updates at a high level will make it easier for the other attendees to follow as well as to understand how this work fits with the work of their own team.

Hold Less Frequently

Scrum of ScrumsSince Scrum of Scrums updates tend to be at a higher level than an individual team's Scrum you'll probably find that you need to hold them much less frequently than the daily rhythm of the team Scrum.  This is because, at this level of detail, the information may not change often enough to warrant getting everyone together on a daily basis.  However, this may not always be the case.  For example, you may find benefit in holding this meeting daily shortly after a project has kicked off or as it nears a major milestone and the pace of change quickens.  As with everything else in Scrum, you'll need to experiment to find out what works best for your team…and then expect that to change as time goes on.

As a result of this, expect the Scrum of Scrums meetings to run a bit longer than a team Scrum.  While there is no set timebox, as there is with a team Scrum, expect these meetings to regularly last 30 minutes if not a bit more depending on the number of teams involved.  This is a result of the difficulty of coordinating the work of entire teams who are often working in different areas of the codebase as compared to individuals on the same team who often work on related features and code.  However, just as with a team Scrum, you should still strive to make these meetings as efficient as possible.

The Most Powerful Tool

The Scrum of Scrums is the most powerful tool in your toolbox when it comes time to scale Scrum to multiple teams.  However, much like the team Scrum, the simple structure of the meeting can be deceptive.  While it's easy to begin holding the Scrum of Scrums meetings, only by keeping the previous points in mind will you and your teams get the most benefit from this powerful practice.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Getting the Most out of Your Scrum of Scrums

Themes versus Epics in 2 Minutes

The difference between themes and epics are a common sticking point for many teams first diving in to user stories. Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably. However, the difference doesn’t have to be so hard.

The difference between themes versus epics are a common sticking point for many teams first diving in to user stories.  Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably.  However, the difference doesn't have to be so hard.

Themes

Themes are a group of related user stories.  Often these stories can be comprised of tasks that may have been too big to fit into a single user story, so they were split into multiples.  An example may be a set of stories dedicated to improve the performance of an app…

User Stories are often represented by sticky notes

  • As a customer, I want to view my last 100 transactions in under 2 seconds, so I can quickly spot inconsistencies.
  • As a loan officer, I want to retrieve a candidate's credit history in under 30 seconds, so I can discuss lending discussions while the candidate is still in my office.

Epics

Epics are a group of related user stories, which all contribute to a common goal.  In nearly all cases these underlying user stories have all been split out of the original epic to allow the team to tackle them over multiple sprints.  As an example, imagine that we've broken the process which allows a customer to analyze the spending trends in their checking account into several stories all comprising the same epic of “As a customer, I'd like to view my spending trends, so I can make smarter decisions.”  The underlying stories may look like this…

  • As a customer, I want to import transactions into my checking account, so they can be analyzed for spending trends.
  • As a customer, I want to view the categorical spending trends from my checking account, so I can see where I tend to spend the most money.

User Stories are often represented by sticky notesAt first glance, the stories that make up the epic may seem very similar to those in the theme.  Each are clearly defined, bite-sized chunks of work.  Each contribute to a larger goal of the system.  However, there's one crucial difference.

While the stories that comprise the theme are not interrelated and could easily be delivered independently from one another, the stories that comprise the epic provide no value until all are delivered.

Diving Deeper

Each of the performance tuning stories in our theme are valuable, and either would likely be appreciated by our users.  However, we could easily deliver the story to improve the performance of viewing recent transactions in one release, and the story to reduce the time to retrieve a candidate's credit score in another. The stories, while related, have no dependency on one another and could easily be delivered independently and in any order.

Contrast this, however, to the stories focused on importing and analyzing transactions from a customer's checking account.  In this case, ordering is important as we will not be able to view a customer's spending trends until we've imported the transactions from their checking account.  However, the ability to simply import transactions provides no real value to a user by itself.  This means that we cannot truly release this story until the second story, to view categorical trends, is completed as well.

The stories that comprise a theme can easily be delivered independent of one another, while the stories that comprise an epic provide no real value until the overarching epic is delivered in its entirety.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Themes versus Epics in 2 Minutes

Stop Estimating Spikes!

The most common question that teams face when first working with spikes is whether or not to estimate these stories. Luckily the answer is simple…don’t.

The whole point of spikes is to help us learn more about stories that we don’t yet know enough about to estimate well. This very unknown nature means that estimating the spike itself would be fruitless. Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.

One of the most common question that teams face when first working with user stories is how to best approach estimating spikes.  Luckily the answer is simple…don't.

The whole point of spikes is to help us learn more about stories that we don't yet know enough about to estimate well.  This very unknown nature means that estimating the spike itself would be fruitless.  Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.

Do Spikes Still Count Towards Our Velocity?

railroad-spikeWhether a spike still counts towards a team's velocity is a hotly debated question.  After all, if a spike isn't estimated then how could it?  To answer this question we must first understand that although we don't estimate spikes…we do timebox them.

Timeboxing Spikes

Each of our spikes should be timeboxed, in story points, and that timebox should contribute to the team's velocity for that sprint.  For example, if we decide that a certain spike should be timeboxed to 3 points then we count that 3 points towards the team's forecasted velocity for that sprint.  This is important because if you're tracking historical velocity to help better predict what the team can accomplish in future sprints, then deducting the time spent on those spikes will skew your velocity which unnecessarily complicates those measurements.

We do this since while a spike may not produce something as tangible as a feature story for a sprint, it may produce value which ultimately benefits the customer…assuming it ties directly to a slated story.  In this way, a spike contributes business value in the same way that the first iteration of a particular UX design contributes business value…i.e., it provides useful knowledge that helps improve later versions of the feature, even if its only to define the path that we shouldn't take.

Knowing What You Want

Whats in the boxHowever, to timebox a spike correctly we need to first know what we want out of it.  This means that we need to define the end goal…i.e, what we want to have learned by the end of the spike.  A great exercise for doing this is to simply ask “Why can't we simply estimate the associated story today?”  The answers to this question then become the spike's acceptance criteria.  As an example, the acceptance criteria for a spike to learn more about the implementation of a new feature may include criteria such as…

  • We have an understanding of the components necessary to build the feature
  • We have an understanding of the impact on existing code
  • We have an understanding of the dependencies necessary to complete the feature

Is this criteria a big vague?  Sure.  But it at least gives you a direction to better understand what you need to have learned during the sprint and the direction that you should be going.

Keeping Spikes Short

Although we are timeboxing our spikes and including them in the sprint, they do have an impact on our overall velocity.  Therefore it's to our benefit to prefer shorter spikes whenever possible.  Not only does this minimize the impact of the timeboxed points alongside the “actual” points of a sprint, but keeping our spikes short also discourages open-ended “exploratory” spikes which may not yield tangible value at the end.

On the contrary, shorter spikes force us to keep them well-defined, which means that they're more likely to produce something of meaningful value to both the team and the customer.

Spikes are an incredibly helpful tool to have our scrum toolbox.  Assigning meaningful timeboxes to them not only help us better understand the impact that they have on our sprint, but it also forces us to better define our desired end result which dramatically improves our odds of getting there.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Stop Estimating Spikes!

Turning Your Standups on Their Head

The daily standup is one of the most powerful tools in the scrum toolbox, so powerful in fact that when teams move beyond scrum they often still retain the standup as one of their core practices. But, there’s still room for improvement.

Few teams doubt the value of the daily standup.  Three simple questions, each designed to help the team plan their next day's work
based on the current situation.

  1. What did I do yesterday?
  2. What am I doing today?
  3. What's in my way?

Paper DollsThe daily standup is one of the most powerful tools in the scrum toolbox, so powerful in fact that when teams move beyond scrum they often still retain the standup as one of their core practices. But what's the real goal of this meeting?  It's to identify areas where the team is blocked so we can get those blockers out of the way.  If this is the case, though, then why do we save blockers until end of each person's update when the team has already started to shift their focus to the next person in line?  In fact, not only has the team started shift their attention, but the person giving the update has often already started to check out!  How many times have you heard a someone simply mumble something about “and no blockers.” when you know for a fact they do?  This is because most people are ready to be done with their update by the last question and just want to move on.  Unfortunately though, they've just skipped the most important part.

Meet the Reverse Standup

The Reverse Standup takes the same three questions as the classic standup and turns them on their head.  The result is that the most important questions are tackled first.

  1. What's in my way?
  2. What am I doing today?
  3. What did I do yesterday?

What's in my way?

This is our classic “what's blocking me question”, and the bread-and-butter of the daily standup.  Think about it like this, if someone is blocked then the next question is irrelevant.  Whatever is blocking your team has to be solved before we can move forward, so we need to start there.

What am I doing today?

Assuming nothing is blocking a team member this question becomes the most important.  This is the information the team uses to build their plan for the day so we tackle it immediately after any blockers.

What did I do yesterday?

Forget for a moment that the classic standup leads off with this question.  Instead think back to your last standup and remember what each person answered for this question.  Now remind yourself that the daily standup is a planning meeting, not a status meeting.  Keeping that in mind, think about how useful knowing what each person did yesterday was to your planning?  Not very, eh? It's not that what someone did yesterday isn't important, its just that it's usually not that useful as input to to creating our plan for today.

Sure there are exceptions: Sally resolved an issue with the test deployment that had been blocking John for the past 2 days, or Steve finished the icon set that Sally had been waiting add to her own feature.  But these are the exceptions rather than the rule.  The vast majority of the time “what I did yesterday” just doesn't impact what we're doing today. And, when it does, it's already reflected on the scrum board.

So what happens to this question?  Well, once a team finds the flow of a Reverse Standup this question starts to feel less relevant.  As a result, many teams eventually make this question optional which results in it being skipped during most standups.  The exception is that the question is only answered when it's relevant to moving the team forward today.

Give it a Try

If you're finding blockers aren't being called out as often as they should, or if you'd just like to breathe some life into a stale standup, give the Reverse Standup a try.  You may be surprised with the result

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Turning Your Standups on Their Head

Type on the field below and hit Enter/Return to search