Jeremy Jarrell - Page 2 of 7 - Agile Made Simple

5 min read

Coaching Your Product Owner As A Scrum Master

September 10, 2018 3:58 pm September 10, 2018

5 min read

Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that…

Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that their responsibility for coaching stops at the Development Team. While coaching of the Development team is important, Scrum Masters must not forget that they also have a responsibility to coach their Product Owners.

However, despite the importance of this responsibility, many Scrum Masters find themselves uncomfortable with the idea of coaching their Product Owners. One reason for this is that the responsibilities of the Product Owner role focus on Product Management, which is an area with which few Scrum Masters have any practical experience.

But there's also another, more insidious reason. In many organizations, the Product Owner is likely to hold a senior title in the organization, such as Director or Vice President. In most cases, these titles are far more senior than the Scrum Master's own title. To make matters worse, while Scrum Masters often come from technical or project management backgrounds, Product Owners may hail from strange lands such as sales or marketing. These lands are likely to be foreign to not only the Scrum Master but to the rest of the Development Team, as well.

This seniority, combined with the unfamiliarity of the role, can put the Scrum Master in an awkward position when they're asked to coach their Product Owner. However, both the Scrum Master and the Product Owner must always remember that inside the walls of the Scrum team…everyone is equal.

Helping Your Product Owner Communicate Their Vision

The good news is that there are plenty of opportunities for Scrum Masters to coach their Product Owners that are not dependent on seniority level or a deep knowledge of Product Management.

One such opportunity is helping the Product Owner understand how they can best communicate their intent to the Development Team. There are many techniques to accomplish this, such as product visioning, product roadmapping or release planning. However, one of the most powerful tools for helping your Product Owner get the details of their vision out of their head and in front of your Development Team is the product backlog.

Scrum Masters often tell their Product Owners that they are responsible for the management of their product backlog. However, those same Scrum Masters are often silent on exactly how to do this.

One area that's ripe for coaching is helping your Product Owner understand how they can better convey their intent through user stories. A Scrum Master can provide invaluable feedback on what the right level of detail is in those user stories to accurately communicate the Product Owner's intent without constricting the Development Team's implementation options. In addition, an adept Scrum Master can also provide advice as to how the right level of detail might change depending on where that item falls in the product backlog.

And speaking of backlog ordering, a Scrum Master can also help their Product Owner understand the different backlog prioritization strategies that are available to them and when it might make sense to choose one strategy over another.

Finding The Right Touch With Your Product Owner

Another common area of coaching is helping your Product Owner understand how they can make themselves more available to the Development Team and why this is important.

Striking a balance between building a strong rapport with the Development Team and micro-managing the team's every move is an act that requires finesse. This can be an excellent opportunity for a Scrum Master to add value as an astute observer who can provide feedback on the Product Owner's interactions with their team.

Being Your Product Owner's Conscience

And finally, an excellent but often-overlooked opportunity for coaching is for the Scrum Master to serve as the Product Owner's conscious. Earlier we mentioned the importance of helping the Product Owner develop a clear vision for the product that your team will deliver. However, even with a clear vision, it can still be easy to be led astray.

In the fast-paced world of product development, new opportunities arise quickly. Key customers may demand capabilities specific to their own business, sales teams may pressure teams for functionality necessary to close a large deal, and competitors may unveil more than enough new features to make any Product Owner jealous.

When these new opportunities arise, it's important for the Scrum Master to help the Product Owner stay true to their original product vision, even in the face of temptation.

One way for a Scrum Master to do this is to continually ask “The 3 W's”:

Who is this feature for?
What need will it accomplish for that person?
Why are we as an organization investing in filling that need?

But merely asking these questions isn't enough. A skilled Scrum Master must also help their Product Owner evaluate whether the answers to these questions match the stated vision for their product, and if they do not, determine whether it's time for that vision to change in response to a previously unforeseen opportunity.

Embracing Your Role As Coach

As a Scrum Master, it's your responsibility to coach your entire team, including your Product Owner.

While this coaching arrangement may at first feel uncomfortable, investing the effort to do so will help improve both the working relationship of your entire team as well as improve the chances that what your team delivers will ultimately provide value to your organization.

Do you want to learn more about how to grow your team through coaching? 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.

No Comments

6 min read

Uncategorized

Dividing and Conquering: Finding the Right Size for Your Team

Jeremy

August 27, 2018 6:00 am August 27, 2018

6 min read

No Comments

6 min read

This post originally appeared on the PivotalTracker blog. Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together…

This post originally appeared on the PivotalTracker blog.

Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together sprint after sprint. And you’ve proven to your organization that this whole “agile” thing can work. In fact, your team has done so well that your organization has decided to reward you by increasing their investment in your team.

After all, if your team has delivered this much value with only a few people, then a team three times that size should be able to deliver the same amount of value three times faster. Right?

Not so fast. While it can be tempting to increase the size of a new team after that team has shown some initial promise, simply increasing the size of an agile team isn’t always the best choice.

How big is too big?

Although it may seem surprising, simply increasing the size of an already successful team is not guaranteed to increase that team’s success—and it may even put that team’s chances of future success in jeopardy.

A team is a complex system and increasing its size increases that complexity even further. As a result, it can become more difficult for the team to continue to function in a high-performing state.

One of the most common areas where this becomes evident is in the increase of relationships and corresponding interpersonal communication pathways that are present on the team. Adding one additional team member doesn’t merely add one additional communication pathway—it adds one additional communication pathway between that team member and every other individual on the team. This increase in communication pathways can significantly increase the complexity of that team’s interactions, especially when that team is following an agile practice that emphasizes face-to-face communication.

Handling the influx of work

However, an increase in the complexity of team dynamics isn’t the only challenge faced by teams who have suddenly increased in size. Another surprising challenge is the ability to keep your new larger team busy.

If asked, most organizations will say that they have more work than they’ll ever be able to finish. In fact, this is often the impetus for increasing a team’s size in the first place. However, what many organizations take for granted is how much of that outstanding work is actually ready to be worked on.

Much of an organization’s outstanding work is vaguely defined or only partially conceived. While this can be perfectly acceptable for work far down a team’s backlog, when a team suddenly finds itself with a sharp increase in capacity, this vaguely defined work quickly makes its way to the top. When this happens, the team suddenly finds themselves tasked with work that seems to generate more questions than answers. As a result, the team cannot process this work as quickly as they expected and their new velocity fails to meet the expectations that the organization had for the larger team.

To complicate matters even further, some of this work may be dated and no longer relevant to the product’s vision or may simply be of low value to the product’s stakeholders. Often a product manager will justify investing in this low-value work as a way of keeping a team busy while higher value work is found. However, this assumption ignores the ongoing maintenance costs the team will incur to support this new work as well as any potential increases in technical debt that were necessary to deliver that work. When the total costs to create and support this low-value work are considered over the long term, we often find that it’s more cost effective to simply keep the team idle until truly high-value work can be identified.

Keeping small teams effective

So, with the all of the challenges that can face larger teams, you may be wondering if simply creating additional smaller teams might be the right choice for your organization. In fact, many organizations find that this can be a very successful approach. Luckily, there are a few specific steps you can take to keep your small teams effective.

The first step is to keep your small teams…well, small. But how small? The Scrum Guide recommends that development teams stay between three and nine individuals. But even the upper end of that range that may be a bit too large for some tastes. Those of us who shudder at the thought of a nine-person team will be happy to know that studies from such management thought leaders as the Harvard Business School or the Wharton School of the University of Pennsylvania have placed the ideal size of a knowledge worker team at five. This means that if you are looking for the ideal size for your teams, around five members per team would be a great place to start.

But size isn’t the only consideration for building an effective team. You must also consider the mix of skills that will be present on that team. Successful small teams are structured in such a way that they are cross-functional and have the right mix of skills necessary to deliver an increment of product with minimal dependencies on other teams. For example, if your team’s delivery flow includes designing a compelling UX for your product, writing the code to realize that UX, and then validating that the entire experience works as expected, then your team should have UX designers, engineers, and testers all committed as part of the team. This will allow the entire increment to be created and delivered without the need of enlisting the help of external teams. This not only increases the team’s sense of ownership over the work they are delivering, but it also allows each individual team to operate more independently within the organization.

Putting this to work for your team

Finding the right size for your team can be a daunting task. Many factors can come into play, including the amount of work that’s defined and ready for your team to tackle, the mix of skills available on your team, and the steps your team must take to ship your product. But by keeping each of these challenges in mind while you structure your teams, and erring on the side of smaller teams, you’ll be sure to find the perfect size for your team.

Are you ready to learn the skills that will transcend any agile methodology your team chooses? Check out the course series ICAgile Certified Professional – Agile Fundamentals from Pluralsight to learn the underlying theories and values that will help you create real and sustainable change in your organization, regardless of the agile approach used by your team. This series discusses common traits of agile teams, self-organization, and, of course, how to discover the perfect size for your team.

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

No Comments

4 min read

Uncategorized

Taking an Active Approach to Transparency in an Agile Team

Jeremy

August 13, 2018 3:09 pm August 13, 2018

4 min read

No Comments

4 min read

One of the driving philosophies of an agile approach is the idea of transparency. Agile teams strive to create transparency both with their stakeholders and within their teams. However, achieving…

One of the driving philosophies of an agile approach is the idea of transparency. Agile teams strive to create transparency both with their stakeholders and within their teams. However, achieving the level of transparency necessary for an agile team to be successful is often more difficult than many teams believe.

Often times, a team will decorate their team space with burndown charts, burn up charts, and the like that convey the progress they are making to their stakeholders every day. And if that same team begins to fall behind then they’ll faithfully update those charts accordingly to ensure they accurately reflect their progress. Unfortunately though, simply updating their charts often is not enough.

However, the shortfalls of this approach are often not evident until the next Sprint Review when the team is frustrated that their stakeholders appear blindsided that the team’s progress was not what they expected. Of course we didn’t hit our velocity, they yell, it was right there on the burndown chart all along!

Taking Responsibility for Transparency

As an agile team, you have a responsibility to act in a transparent way, but doing so means more than simply hanging a few charts in view of your stakeholders and calling it a day.

In order to achieve true transparency with your stakeholders you must work to actively foster that transparency with everyone involved. This means regularly engaging your stakeholders in conversation, showing them the locations where you’re currently surfacing information, and teaching them to how to decipher and glean the information they need from each location.

For example, if your team begins to fall behind their forecasted velocity for the Sprint simply posting a burndown chart on the wall and assuming that your stakeholders have been informed isn’t a successful strategy. Instead, seek out your key stakeholders and call their attention to your burndown chart, ensuring that they understand what it conveys and what it means for your project. You can then use this opportunity for a deeper conversation of how your team and stakeholders can work together to still achieve your overarching goal for the Sprint, such as by removing some stories from the Sprint plan that don’t contribute to that goal or by reducing the scope of the remaining stories.

As another example, allowing your Sprint Reviews to devolve into a passive demo where your team simply demonstrates the work they’ve completed to a panel of disinterested and disengaged stakeholders is unlikely to garner the feedback you need to move your team forward. Instead, make an effort to ensure that the right stakeholders are in the room to decide whether your team is truly on the right track, and then work to force a productive conversation to identify what needs to change in the next Sprint in the event that they aren’t.

Achieving True Transparency

While simply working in a transparent manner in your day-to-day activities will garner a passive level of transparency, to truly achieve the benefits of agility you must actively promote transparency through every facet of your team’s process.

This includes actively engaging your stakeholders in your team’s delivery process, teaching them how to get the information they need from your team’s information radiators, and bringing them into fold so that everyone is equally vested in a successful outcome for your project. In fact, teaching your stakeholders to accurately decipher your team’s information radiators may even result in those stakeholders spotting patterns and or insights that your own team may have missed, deepening the value that those relationships bring to your team.

If you want to truly create a level of transparency between your team and stakeholders then simply hanging a burndown chart on the wall often isn’t enough. To achieve true transparency, you need to engage your stakeholders every step of the way and ensure that they are actively aware and engaged throughout your project.

Are you ready to learn the skills that will transcend any agile methodology your team chooses? Check out the new course series ICAgile Certified Professional – Agile Fundamentals from Pluralsight to learn the underlying theories and values that will help you create real and sustainable change in your organization, regardless of the agile approach used by your team.

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

No Comments

5 min read

Uncategorized

Should A Manager Be A Scrum Master?

Jeremy

July 23, 2018 6:00 am July 23, 2018

5 min read

No Comments

5 min read

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding…

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding “no”. In fact, the Scrum framework intentionally keeps these two roles separate in order to encourage a healthy tension between the needs of the development team and the ultimate needs of the organization.

However, when posing this same question in the context of the Scrum Master and the Development Manager, the answer becomes less clear. This is primarily because while the Scrum framework clearly describes the roles of Development Team, the Scrum Master, and the Product Owner, Scrum has no concept of the role of the Development Manager. This means that the Scrum framework offers no guidance to how this role should relate to the Scrum Master role.

Considering The Ideal Traits Of A Scrum Master

To better understand how these two roles might relate to one another, let’s take a moment to consider their responsibilities.

In addition to all of the responsibilities that are defined for Scrum Masters, one of the most important qualities of a Scrum Master is that they are viewed as a Servant Leader to their team. Servant leadership is a deep topic, but some of the qualities of a true servant leader are that they share power with their team, they put the needs of others first, and they put a strong emphasis on helping those with whom they work with grow both professionally and personally. In fact, one of the most telling traits of a servant leader is that rather than believing that their team is there to serve them, they instead flip the pyramid and believe that they exist to serve their team.

Comparing These Traits To A Development Manager

Let’s compare the approach of servant leadership to that of a traditional Development Manager. While there are managers who are exemplary servant leaders, the traditional definition of a manager is one who has functional authority over their team.

One aspect of this is that these managers often have hiring and termination authority over their team, which can significantly alter the dynamic that exists between the Scrum Master and their team.

In addition, many managers are also responsible for the day-to-day tasking of their team. While this may seem to be a simpler and more reliable approach for many organizations, it flies directly in the face of the principle of self-organization that a Scrum Master should be attempting to instill in their team.

Dreaming The Impossible Dream

With so many core differences between the Scrum Master role and the Development Manager role you might think that combining the two successfully is impossible. But this isn’t actually the case. While it can be incredibly rare, the right individual can find success in both roles.

To do this, that individual must be keenly aware of the responsibilities of each role and where they might conflict with one another. For example, such as how the expectation that a manager provide day-to-day tasking to their team conflicts with the very qualities of self-organization that they should be trying to grow in that team.

In addition, where these conflicts exist this individual must also make it clear to their team when they are wearing the hat of a manager, when they are wearing the hat of a Scrum Master, and when they are trading one hat for another. This explicitness in the role that they are currently serving can help provide the context that their team needs to best interpret the Scrum Master/Manager’s advice.

Making The Most Of A Bad Situation

While combining the Scrum Master and Manager roles can be challenging, it may not be without its perks.

Scrum Masters often encounter tough organizational impediments that can be challenging to resolve on their own. Such impediments might include responsibilities outside of the sprint that are distracting members of the Scrum team or an inability to secure key hardware or computing resources that are necessary for the completion of a key story. But by leaning on their role authority as a manager in the organization, Scrum Master/Managers can often facilitate the removal of these impediments much easier than that of a non-manager Scrum Master.

In fact, a successful Scrum Master/Manager can even use their authority to grant greater latitude to their team which better empowers their team to take on more responsibility, moving them closer towards self-organization.

So while combining the Development Manager and Scrum Master roles is far from an ideal situation. An individual with a keen sense of the responsibilities of each role can still find success in this difficult situation. In fact, the right individual might even be able to use the unique combination of these roles to their advantage.

Want to learn more about how to make Scrum work in your unique environment? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their Scrum adoption.

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

No Comments

5 min read

Uncategorized

Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning

Jeremy

July 9, 2018 1:14 pm July 9, 2018

5 min read

No Comments

5 min read

This post originally appeared on the PivotalTracker blog. We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint…

This post originally appeared on the PivotalTracker blog.

We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint and you never even made it to sizing. By the time the session was over, you were no closer to having the next sprint planned and all that you’ve gained for your trouble is a frustrated and disheartened team.

If this sounds familiar, then it might be time to consider backlog refinement. Backlog refinement is a practice intended to help you keep the top of your backlog in a refined state so you can have better sprint planning sessions. But despite the value backlog refinement can yield, there is no officially prescribed approach for how to do it. However, if you’re looking for a simple way to introduce this practice to your team, then don’t despair: there’s an easy approach that you can use with your team today.

Blocking and Tackling Your Backlog

The *blocking and tackling* approach consists of two separate refinement meetings spaced evenly throughout each sprint. For example, if your team operates on two-week sprints, then you might hold the first session on the first Wednesday of the sprint and the second session on next Wednesday of the sprint.

Blocking

In the first session, known as *blocking*, your goal is to select the stories that you expect your team to work on in the next sprint. Your selected stories will be a function of both your planned goal for the next sprint and your team’s forecasted capacity for that sprint. If your backlog has already been prioritized so your most important stories are near the top, and these stories already have a rough estimate applied to them, then this process tends to be relatively straightforward. However, it’s still helpful to do this session with the help of your team for two reasons.

First, sharing more detail about your goal for the next sprint and which stories you believe will enable that goal helps your team better understand the bigger picture of what they are trying to create. This understanding will allow them to make decisions in the current sprint that will put them in a better position to accomplish the work selected for the next sprint.

Second, while your team will save their final estimates for the next sprint planning meeting, they can often share their impression of whether or not the work selected seems too large for the next sprint—or even too small. If it turns out that the work you selected isn’t quite the right fit, then you have the rest of the sprint to decide how to adjust your selection accordingly.

The rest of the session is saved for discussion. Introducing the stories you’ve selected to your team often leads to questions and discussions about alternative approaches…many of which you may not have considered. Surfacing these questions before the sprint planning meeting allows you to take time before the next refinement session to find the answers your team needs to confidently move forward.

Tackling

The second session, known as refinement, is where the real work happens. During this session, you will work with your team to further refine the selected stories to ensure that they’re ready for the next sprint planning meeting.

This session begins with you reviewing the selected stories for the next sprint to help refresh your team’s memory of what was selected. This is also a great opportunity to call out any changes that were made to your story selection to better fit your team’s forecasted capacity.

Next, take the time to provide any answers to questions you were unable to answer in the previous session. Not only does this help further refresh your team’s memory of their concerns regarding each story, but it also improves the chances of productive discussion later in the session.

Once you’ve answered any outstanding questions, give your team the opportunity to ask any questions that may have occurred to them since the last refinement session. Your team has now had several days to more thoroughly consider their approach to these stories; therefore, a few questions are to be expected. This is their chance to pose those questions to you before the deeper discussion begins.

Finally, the remainder of session is focused on ensuring that the selected stories are in a *ready state* for the next sprint planning session. Many high-performing teams already have a checklist in place of what they consider necessary for a story to be ready for discussion in an sprint planning meeting. The contents will vary, but at a minimum they often specify that a story must have a brief description of its objective, acceptance criteria, and a rough estimate.

If your team doesn’t have a checklist of its own yet, then the INVEST criteria is a great place to start. INVEST specifies six qualities that are often associated with well-refined stories. Try comparing each of your selected stories against the INVEST criteria to see what gaps it exposes. After several sprints of this, you’ll likely start to recognize which qualities seem to add value to your team and which qualities do not. Once this happens, feel free to adapt the INVEST criteria to your own set of criteria that makes the most sense for your team.

Getting the Results You Need

Regularly holding backlog refinement sessions will result in smoother sprint planning meetings and, ultimately, more predictable sprints. However, the approach outlined above should be considered a starting point, so don’t be afraid to adjust this practice to better fit the needs of your team.

Regardless of how you ultimately approach backlog refinement for your team, what’s important is that your team is always ready to start the next sprint and that you or your team never have to suffer through a painful sprint planning meeting again.

Are you a Product Owner who wants to help your team better understand your vision for your product. Or do you want to understand how you can work more effectively with your development team? Check out my course series Product Owner Fundamentals, part of the Using the Scrum framework learning path from Pluralsight, to learn how you can use Scrum to help your team deliver great products that your customers love.

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

No Comments

7 min read

Uncategorized

Using An Estimation Grid To Improve User Story Estimation

Jeremy

June 4, 2018 6:00 am June 4, 2018

7 min read

No Comments

7 min read

Estimation is tough. We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as…

Estimation is tough.

We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as well as the challenge of estimating something’s complexity. In fact, due to the abstract nature of estimating in story points, teams find that their goal is less often accurate or precise estimates, but more often consistent estimates.

Although we often struggle with assigning specific values to items we’re actually quite good at assigning relative values to objects. For example, few of us could glance at a bucket of water and estimate exactly how many ounces that bucket will hold. But, we could easily estimate that the bucket holds more ounces than a glass and less ounces than a swimming pool.

Teams can also apply this same relative estimation technique when estimating a particularly tricky piece of work. However, this is often done by estimating new stories relative to the size of other stories that the team has not yet worked on, such as other stories that have also been selected for the sprint.

While any relative estimation can be helpful, it can be more helpful to compare new stories to stories that have already been delivered and that the entire team agrees were estimated correctly.

Meet the estimation grid

One of the most powerful ways to do this is with the use of a tool called an estimation grid, which is simply a grid containing a cell for every other number in your team’s estimation range.

For example, if your team estimates using the values in the Fibonacci sequence from 0 to 13 then your estimation grid would look like this.

In each cell, place a sticky note representing a story that your team has recently completed that everyone agrees was indicative of its original estimate. For example, if in the last sprint your team completed a story that was originally estimated at 3 points, and everyone still agrees with that estimate, then place it in the cell for 3.

Putting the estimation grid to work

Once the grid is built you can begin working through your estimation routine as normal, such as by playing a few rounds of Planning Poker. However, once your team gets stuck on a particularly tricky story then it’s time to refer to the grid.

For example, imagine that your team is trying to estimate a story to add support for a new payment gateway to your ecommerce app. While the act of supporting the new gateway seems straightforward, it will involve touching a particularly complex piece of the codebase. For this reason, many of the team are unsure of how to estimate this story.

But by comparing this story to the reference stories already found on the estimation grid, your team is able to spot key similarities between this story and the reference 3 point story, such as a relatively straightforward set of business rules coupled with a complex area of the codebase. As a result, the team estimates this story as a 3.

Later, when the team finds themselves stuck on another story to add a simple CSV export to an existing report they return to the estimation grid. However, this time the answer is not as straightforward. While they find that adding this export seems more complex than the reference 1 point story, it’s not quite as complex as the reference 3 point story. But since the complexity of the story seems to fit neatly between these two reference stories your team assigns the story an estimate of 2.

Getting the most out of your estimation grid

While the estimation grid is already a powerful tool, there are a few things that you can do to get even more out of this tool.

First, resist the urge to use the estimation grid for every story that your team encounters. You’ll still want your team to be able to evaluate the complexity of each story through discussion and shared discovery rather than simply defaulting to comparing every story to the same handful of stories. Your estimation grid should be an aide, not a crutch, so only refer to it when needed.

Next, be prepared to update your estimation grid periodically. As the work your team is doing evolves they’re likely to begin working with different technology stacks, in different areas of the codebase, or with different themes of your product. Occasionally checking that your reference stories reflect these changes and replacing those that do not will help keep your reference stories relevant to your team’s needs.

Finally, resist the urge to create a cell for every value in your team’s estimation range. For example, you may have wondered why we didn’t create a cell for each value in the Fibonacci sequence from 0 to 13. There are two reasons for this. First, finding a canonical reference story for each value in that range can become tiresome, especially for those values that your team rarely uses. But second, and most importantly, you don’t want to paralyze your team with too many choices.

Generally, speaking humans make decisions easier when presented with fewer choices. For more on this, you can check out this article from Harvard Business Review, but for our purposes simply know that presenting your team with more choices to compare a tricky story to is likely to make act of the estimation longer rather than shorter. Instead, keeping your estimation grid simple and only giving your team just enough options will help keep the entire estimation process as painless as possible.

Wrapping up the session

Once your planning session is complete, a great way to wrap up is by laying all of your team’s estimated stories over your estimation grid and looking for patterns or clusters. For example, did it seem as if your team estimated the majority of their stories at the high end of your range? Larger stories are more complex and, as a result, tend to be less well understood. While a single large story in a sprint is unlikely to be a cause for a concern a sprint that’s primarily comprised of large stories is likely to be a very risky endeavor.

Or does your sprint seem to have many 0 point stories? While some stories may be so simple as to feel as if they do not warrant a point, no story is truly free. Every story takes time and attention from your team to deliver. While a few 0 point stories may not be cause for concern, many 0 point stories can add up and threaten your team’s chances of delivering everything they’ve planned for the sprint.

While the right answer is going to vary for every team, generally speaking I like to see most of a team’s stories clustered in the lower end of their estimation range. Stories this size tend to be just large enough that you can understand the impact that each story will have on our team’s velocity but are not so large to contain large amounts of unknown.

If your team’s sprint doesn’t seem to be clustered as I just described then don’t panic, you can simply take some of your larger stories and try to split them into smaller stories to reduce your risk. And if your team gets stuck estimating some of those newer stories then now you have a tool to help them.

Want to see more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.

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

No Comments

7 min read

Uncategorized

The Destination Is The Goal, Not The Journey

Jeremy

May 28, 2018 2:14 pm May 28, 2018

7 min read

No Comments

7 min read

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal. A team’s…

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal.

A team’s goal should be a specific and measurable piece of business value that the team plans to deliver within a certain timeframe. For example, some great ideas for goals might include a new feature set that sets your product apart from its nearest competitor or a fresh look and feel and for an older feature set. Or, rather than being user-facing, a valuable goal might the delivery of a new capability or service that’s useful to the rest of the organization, such as a significantly improved build pipeline.

Whatever the goal may be, high-performing teams clearly define the goal that they intend to achieve at the outset of each sprint so they have a shared understanding of the objective that they will all be striving towards.

Velocity is different

Velocity, on the other hand, is simply the sum of the estimated effort that the team completed during the sprint in pursuit of their stated goal. For example, imagine that during the last sprint your team completed the following stories:

Story A: 3 points
Story B: 8 points
Story C: 5 points
Story D: 1 point
Story E: 1 point

Based on this list, we know that your team had a velocity of 18 points in the last sprint.

Was your team’s overarching goal to deliver 18 points the last sprint? Probably not. Most likely, your team’s goal was something that held the promise of a more tangible piece of business value, such as a social sign-on capability to encourage more users to create accounts, or a streamlined build process.

The 18 points of velocity that your team achieved during that sprint was nothing more than a byproduct of the progress that they made towards their goal. This is because, by itself, the act of delivering 18 points yields no value to your organization. At it’s best, it might serve as a correlation to the value that your team produced during the same timeframe, but only if you assume that your team had only selected high-value work to tackle during that time.

Making this stick

If this sounds familiar to you, then you’re not alone. Most agile coaches find themselves repeating this point on a regular basis. But, despite how many times most organizations have heard this story, it simply never seems to stick. So, in hopes of making this stick, let’s look at an analogy to this problem based on another problem that you probably already intuitively understand.

Imagine that you’re planning a trip to the beach with your family. Your entire family has been looking forward to this trip and are anxious to arrive. However, the beach is far from your home and it will take most of a day to drive there.

You’ve done some initial planning using your GPS and have discovered that the beach is 520 miles from your home. You also know from your experience with previous, similar trips that you can cover about 65 miles per hour in your car. This means that, roughly speaking, it should take you about 8 hours to drive your family to the beach…or 520 miles divided by 65 miles per hour.

If you relate this problem to our previous discussion then it should be easy for you to recognize that your goal is to arrive safely at the beach. The 520 miles between your home and the beach is simply an initial estimate of the effort required to achieve that goal. And finally, the 65 miles that you expect to cover per hour is your forecasted velocity per hour, based on similar trips in the past.

Simple right?

Simplicity, meet reality

If you’ve ever taken a long-distance trip then you probably know that trips are rarely as simple undertakings as they first seem. Although we may start our trip with the best-laid plans many unexpected events often emerge to disrupt those plans.

For example, your initial estimate of a traveling speed of 65 miles per hour most likely assumes that the majority of your time will be spent traveling at a constant speed on the interstate. But, few of us are lucky enough to have an interstate that runs directly from our front door to our favorite shoreline. As a result, you’ll most likely have to spend a bit of time at the beginning of your trip and the end of your trip traveling on secondary roads. This means that you should expect to travel less miles than you’d originally planned during those times, which means that you should also expect some variation in your speed throughout your trip.

In addition, even the most ambitious amongst us wouldn’t attempt an 8 hour trip with our families without a few short courtesy stops for everyone to stretch their legs. In fact, most of us would even grant a longer stop for lunch.

But most importantly, every great travel planner knows to expect the unexpected. Traffic jams, road closures, out-of-the-way detours, or even inclement weather can all emerge to slow you down while pleasant surprises like unexpected shortcuts can give you a boost in the right direction.

Any trip offers the possibility of unexpected developments, any one of which could affect your overall travel time. In fact, the longer the trip, the more possibility there seems to be for those plans to go awry.

Remembering the goal

If you’ve ever taken a long trip, then none of the twists that I threw at you in the example above would have been surprising. Difficult road conditions? Sure. Inclement weather? Of course. Unexpected stops along the way? Absolutely.

But, if you’re like most people, when I gave you my first estimate of 8 hours of travel time, which I arrived at by simply dividing our expected effort by our average forecasted velocity, these types of issues were probably the furthest thing from your mind.

However, even with those unexpected developments, if you arrived at the beach safely then you’d likely still consider the trip a success. This because arriving at the beach is your ultimate goal, not the trip to it.

If your goal had simply been to drive 500 miles in your car, then you could have just driven 250 miles in one direction out of your front door, turned around, and drove 250 miles back. Or, if your goal had only been to spend 8 hours in your car, then you could have just driven in circles around your block for 8 hours.

When applied to analogy like this the idea of driving circles around your block for 8 hours and considering that a success seems ridiculous. “Of course I wouldn’t do that” you say, “the goal was to get to the beach…not to spend some arbitrary number of hours in my car driving aimlessly.”

But if this is the case, then why is it that so many organizations judge the success of their teams only on whether that team closed an arbitrary number of points in a given a timeframe with little regard for the work the team ultimately produced while earning those points?

The next time your organization holds a sprint review in which the focus is solely on the number of points closed rather than the value that those points delivered, remember: the destination is the goal, not the journey.

Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.

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

No Comments

6 min read

Uncategorized

Starting Your Team On The Right Foot With Team Chartering

Jeremy

May 7, 2018 6:00 am May 7, 2018

6 min read

No Comments

6 min read

This post originally appeared on the PivotalTracker blog. One of the best things that you can do to help your team deliver great products is to make sure your entire team…

This post originally appeared on the PivotalTracker blog.

One of the best things that you can do to help your team deliver great products is to make sure your entire team is starting off on the right foot.

A great way to do this is by creating a team charter, which is a document that formally describes how a team will work together. But in order for a team charter to be effective, the entire team must be vested in its output. To accomplish this, they must be actively involved in its creation; otherwise, if the team feels like the charter has been forced upon them, they’ll be more likely to reject it.

If you’re lucky, all members of your team will be fully committed to your team.

Defining How The Team Will Work Together

Team charters are often created as the team first begins to take shape and may persist across multiple projects throughout the team’s lifetime. While many of the specific details of a team charter may vary depending on the type of product the team is creating, the technology stack they are working with, or even the dynamics in play in their broader organization, generally speaking, most team charters will answer the following questions:

What Is The Vision For The Team?

The team charter should clearly state what the team will accomplish together. For example, if your organization is making its first foray into the mobile space, then the team’s vision may be, “To successfully deliver the organization’s first mobile application to market.”

What Are The Team’s Values?

The team charter should also define what qualities will be important to the team as they accomplish that vision. For example, does the team prize craftsmanship in the code they create, mutual respect across the entire team, or active learning and continuous improvement? Regardless of what values your team holds dear, asking them to actively consider and commit to those values greatly increases the chances that they will be upheld.

Who Is On The Team?

If you’re lucky, all members of your team will be fully committed to your team. However, many teams must contend with members who are shared across multiple teams or who are available to their team but not actually a part of it. A team charter should clearly specify who is on the team and in what capacity to help address directly any ambiguity about each member’s availability.

This is also a great opportunity to clarify what the roles of each member of the team will be. Simple roles such as Product Manager, Engineer, or Tester are often more than sufficient to help the team start to form a picture of how it can work together, as well as help new members quickly orient themselves to who they will be working with.

What Are The Ground Rules For The Team?

Finally, the team charter should clearly define what will be expected of each member while they are on the team. Often these expectations will be influenced by the values that the team stated earlier in the chartering process. For example, if your team values face-to-face collaboration across the team, then they may establish a ground rule that all members of the team are expected to work in the office during established core hours. On the other hand, if your team values individual responsibility, then they may establish a ground rule permitting working remotely, but clearly specifying by what communication channels each team member is expected to be available.

Regardless of what rules your team specifies, they should make it clear what is expected of each team member if they wish to remain in good standing with their peers.

Keeping The Team Charter Relevant

While your team should periodically have the opportunity to revisit their charter to ensure that it accurately reflects the way they want to work, this should not occur too frequently. Your team’s charter should serve as a touchstone for how the team will operate and changing it too frequently will inhibit the team’s ability to absorb the way of working they’ve defined for themselves.

Ideally, revisions to the team charter will best occur alongside major milestones or other opportunities for reflection and long-term planning. For example, after your team ships a major release of their product might be a good opportunity to consider revising the team charter based on the team’s experience in the last release. Or, if your organization operates on an annual planning cycle, then this can also be an opportunity to revisit the team charter’s in preparation for the coming year.

Even if your team has already formed without the benefit of a charter, it can still be beneficial to go through the process of creating a team charter. Creating a team charter with a team that is already established can be a great opportunity to level set a high-functioning team to ensure it continues operating at optimal levels, or even to reboot a team that may struggling. In either case, creating a team charter can give your team the opportunity to identify and capture what’s working well as well as to voice their concerns about what isn’t.

Getting The Most From Your Team’s Charter

Regardless of the terms that your team specifies for their charter, to get the most out of it the entire team must commit to respecting and honoring the terms they’ve agreed to. In addition, the team must also be committed to offering feedback on the charter and incorporating that feedback into future versions when opportunities for improvement arise.

If your team is committed to creating a charter that adds value to the way they work, and then honoring that charter after creation, then a team charter can be an excellent tool for starting your team on the right foot towards delivering a successful product.

Want to learn more about helping your team reach their true potential? Check out my course Scrum Master Fundamentals: Growing Yourself and Your Team for more tips on helping your team become their very best.

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

No Comments

5 min read

Uncategorized

Writing Great User Stories For Developing APIs

Jeremy

April 23, 2018 2:48 pm April 23, 2018

5 min read

No Comments

5 min read

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would…

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would be creating APIs. For example, should the user story be written from the point of view of the API, such as “As an API, I want to…”, or should the persona portion of the user story be dropped entirely, focusing instead on only the intent and the justification.

As more and more teams find themselves tasked with creating APIs this is becoming a very common question. But luckily, there’s an approach to writing these types of user stories that can still help the team understand the intent of these stories without sacrificing their essence.

APIs Aren’t People

Most of know that creating an API persona for these types of stories simply doesn’t feel like the right answer. But explaining exactly why this isn’t the right answer can be harder to put your finger on.

To better understand why this feels wrong we have to remember some of the goals of user stories. First and foremost user stories are intended to improve collaboration with your team. However, they also have additional benefits, as well.

One of these additional benefits is to help you understand how the features you are designing will benefit the intended users of your product. Note the keyword there: users. This is critical, since without first understanding the users of your product, you can’t hope to design the features that will yield the most benefit to those users.

Another additional benefit is that well-crafted user stories help you understand the ultimate value that each story will be creating. This can help you can better understand if that value is worth the investment required to bring that story to market as well as when would be the optimal time to make that investment.

Note that neither of these benefits are possible if you don't have a properly-crafted and realistic persona already attached to each story. The lack of a realistic persona not only impedes your ability to make the necessary prioritization decisions as a product owner, but it also deprives your team of the context they'll need to make better informed technical decisions along the way.

Defining A Realistic Persona

So if creating a persona named API isn't the right choice for these types of stories then what is? The best choice is to identify the persona who will ultimately benefit from the value that the story will deliver and then attach the user story to that persona.

For example, imagine that you are creating an API that allows for conversions between different currency units. As part of this story you would like to convert between the Euro and the US Dollar. You could write the story as follows:

“As an API,
I want to convert between the Euro and the US Dollar”.

While this user story does convey the action that you wish to accomplish it lacks critical context. Who needs to do perform this action…the API? That's not very helpful. And what about the why?

While this story does tell the team what you want achieve, it lacks the necessary context to help the team make better decisions in development as well as to help you decide where this story fits in your overall product strategy.

Understanding Who Stands To Benefit

Imagine that you discover that your API will be used by a commodities trading house. And furthermore, imagine that you have a persona called “Commodities Trader” who represents someone who trades global commodities. Let's revisit the story in this new light.

“As a Commodities Trader,
I want to convert between the Euro and the US Dollar,
so that I can better understand how the price of my target commodity will be affected by currency fluctuations.”

This version of the story gives us much more context to work with. For example, understanding that this conversion will be used for comparing currency valuations helps our team better understand what level of precision will be needed in their conversions. And understanding that this conversion is intended to be used for commodities trading gives you much more context as a product owner to understand where this story might fit in your overall product strategy.

For example, if the trading volume between the European Union and the United States is relatively low today then this story can probably be delayed in exchange for higher priority work. On the other hand, if this trading volume is currently high then your product would likely benefit from tackling this story sooner rather than later. And finally, since we now know who will be using the feature and why they will be using it, we now have more information to find other stories in our backlog that might complement this story and therefore should be delivered alongside of it.

Putting This To Work In Your APIs

Features should exist only to yield value to your product’s users and ultimately your stakeholders. And user stories should exist to give your delivery team the context they need to make better informed decisions along the way. But without a well-crafted persona attached to each user story, you risk investing your team’s effort only to deliver stories that completely miss the mark for both your users and your stakeholders.

Want to find the perfect next hire for your team? Check out my Agile Developer Assessment on Kand.io, the leading tech-talent assessment platform. This assessment will help you find the perfect fit for your growing agile team.

No Comments

8 min read

Uncategorized

How To INVEST In Your User Stories

Jeremy

April 9, 2018 12:21 pm April 9, 2018

8 min read

No Comments

8 min read

This post originally appeared on the PivotalTracker blog. If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation,…

This post originally appeared on the PivotalTracker blog.

If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation, but the key to starting that conversation is a good story.

For example, imagine that your team is building an e-commerce site that enables college students to sell their books to other college students at the end of the semester. Rather than selling to an intermediary, such as a university bookstore, this site would let college students to sell their unused textbooks directly to their peers, thus allowing them to keep more of their profits. As a product manager, you might start the conversation with your team with this story:

As a college student

I would like to sell my old textbooks

so I can make money.

On the surface, this story seems to have all of the basic building blocks of a great user story. It clearly specifies a target persona that will benefit from the new capability described by the story, specifies what that new capability should be, and even describes what value the persona will receive from that capability.

But is this story enough to start the conversation with your team? What if there were a simple test that could tell you?

Meet INVEST

Luckily, there is a practice that can help, and it’s called INVEST. INVEST represents a specific set of qualities that mature stories tend to exhibit. Although not every quality will apply to every story, the more qualities that your story exhibits, the more likely it is to be ready for consumption.

So what are these qualities? INVEST represents these six qualities that are often considered desirable in a user story:

- Independent: The story can be delivered independently of other stories. Note that this doesn’t mean that stories can’t have prerequisites, only that the stories may not be so coupled that they must be delivered in parallel.

- Negotiable: While we prefer stories written in a clear and unambiguous language, stories should not be written to such a level of detail that they become overly restrictive and prevent your team from arriving at the best solution themselves.

- Valuable: Every story that’s delivered should make your product more valuable—period.

- Estimable: Every story should provide enough information to equip your team to make a reasonable estimate of that story’s complexity. This is because whether or not we can estimate a story’s complexity is often a great indicator of how well we actually understand that story.

- Small: Smaller stories are easier for your team to understand and therefore are simpler to deliver. Plus, the smaller a story is, the less risk that may be lurking under its covers.

- Testable: For each story that you write, you should be able to determine whether what was delivered met your expectations. To do this, the story must be written in a clear enough manner as to remove any ambiguity of what the end result should be.

Let’s look again at our story from before, but this time through the lens of INVEST.

As a college student

I would like to sell my old textbooks

so I can make money

For example, does “sell my old textbooks” describe a story that is small and independent? Perhaps not. Although this higher-level description does leave room for negotiation of how your team can best deliver the story, a more specific description may better enable that negotiation. What if you revised this story to better reflect how a college students may sell those textbooks?

As a college student

I would like to list my old textbooks for sale

so I can make money

This new version provides your team with a more refined vision for this capability that not only reduces the ambiguity and scope of the story, but also makes it more estimable because the team now has a better idea of what you have in mind. And because the story is now more clearly defined, it’s more testable, too.

But what about value? Is making money really the ultimate value that this story might yield to the college student? That’s definitely an end result, but this value statement doesn’t necessary add context to the story. Great value statements help your team better understand the why behind the story by providing clues to what a user might stand to gain after the story has been delivered. Let’s try to rework this story’s value statement to make that more clear.

As a college student

I would like to list my old textbooks for sale

so I can sell my textbook to the highest bidder.

That’s better. Your team now has a clearer understanding of what value the story will yield to the user once it’s delivered, which will provide clues to the complexity that may be inherent in this story. This additional context will better enable your team to negotiate tradeoffs that may allow them to deliver the story more effectively.

Getting more from INVEST

So now that you’ve seen what the individual qualities of INVEST are, let’s talk about how you can use INVEST to improve the quality of your own stories. To do this, we’ll start by talking about what each of these qualities has in common.

First, notice that while each of these qualities asks for a simple “yes” or “no” answer, how you arrive at that answer is subjective. For example, is your story valuable? Before you can answer yes or no, you must first define exactly what value means to your product as well as how that value will be measured. What about negotiable? Is your story negotiable enough? Once again, it’s up to you and your team to agree on how you strike the balance of defining your stories clearly enough so that they’re unambiguous, but not so well defined that they restrict your team’s creativity. This fostering of a deeper discussion across your entire team is the magic of the INVEST technique at work.

Next, notice that many of the INVEST qualities seem to support other qualities. For example, smaller stories naturally lead to more testable stories because smaller stories naturally become more concise and less coupled to other stories. Additionally, smaller stories also tend to be more estimable because these stories are naturally easier for a team to understand.

But not all qualities set up such a natural, virtuous circle. In fact, some qualities act as a balancing force to other qualities. For example, while in general we may prefer smaller stories, we don’t want to create stories that are so small that they don’t yield any meaningful value. For example, we want to avoid breaking stories into such small pieces that each piece is too small to move the product forward on its own.

Putting INVEST to work for you

Ensuring that your stories adhere to the qualities described by the INVEST technique can result in significant improvements to not only your stories but also your own communication with your team. But where should you start?

It would be unrealistic to expect that every story in your product backlog conforms to INVEST. Not only would this be time consuming, but overinvesting your time in stories further down your product backlog might also discourage you from changing those stories as you learn more about them in the future. Instead, INVEST is most appropriate when applied to those stories that are on deck for your next iteration. At this stage, you can be reasonably confident that you’ll make the investment in delivering those stories and you will have also learned more about those stories from your experience in previous iterations. At this point, it makes sense to spend the extra time ensuring your stories adhere to the INVEST qualities to improve your communication with your team.

By applying INVEST to those stories that are on deck for your team to deliver—and applying this technique at the right time—you can dramatically improve the level of communication between you and your team, which will dramatically improve the quality of the product that your team ultimately delivers.

Want to learn more ways to help your team get the most out of user stories? 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.

No Comments