Jeremy Jarrell

Agile Made Simple

Tag: scrum

7 min read
Uncategorized

How to Handle Stories That Aren’t Completed in a Single Sprint

7 min read
No Comments on How to Handle Stories That Aren’t Completed in a Single Sprint
7 min read

One of the most common questions new Scrum teams face is how to handle stories that were not completed in one Sprint and must be rolled into the next Sprint….

One of the most common questions new Scrum teams face is how to handle stories that were not completed in one Sprint and must be rolled into the next Sprint. While there is no universally-agreed-upon guidance for how to handle this, here is an approach that I've found that seems to work well for most teams.

Dealing with Stories That Roll Into the Next Sprint

Whenever your team finds an incomplete story at the end of the Sprint, simply roll that story, in its entirety, into the next Sprint. When this happens, no points should be awarded to the team, for partial completion of the story.

Furthermore, I recommend that teams do not re-estimate the remaining effort of the story in the next sprint. However, I do recommend that the team take this opportunity to reevaluate their estimate for the entire story. For example, to consider whether anything has been learned during the previous Sprint that would indicate that the story is more or less complex than the team previously thought. This is also an excellent chance to consider whether the team may now see a simpler, alternative approach that wasn't obvious before.

However, if the estimate for the story does change remember that the estimate should represent the complexity of the entire story, not just the portion that remains.

Seeing This in Action

To better understand how this approach works, let's look at an example. Imagine that your team began work on a story that was estimated at 8 points in Sprint 1. However, rather than completing the story in its entirety, your team only gets 70% of the way through the story before the Sprint ends and then must roll that story into Sprint 2.

At the end of Sprint 1, your team is awarded no points for the story in question, even though your team reports that the story is 70% complete. Instead, the story is rolled into Sprint 2 with the full 8 point value. Once the remaining 30% of the story is completed in Sprint 2, the team is awarded the full 8 points for completing the story.

Understanding the Benefits of This Approach

There are several benefits to this approach. One of the most important is that failing to award teams “partial credit” for work completed reinforces to your team their goal is to deliver value, not to simply stay busy. In most cases, a story that's 70% complete doesn't deliver 70% of that story's potential value; it delivers no value. As a result, it shouldn't yield any points for the team.

Now taking this approach is likely to upset your team, but arguably that's a good thing. One reason is that taking this approach will further focus your team on value delivered, rather than the effort expended. Another reason is that this approach will encourage your team to continue to break their work into smaller stories.

Smaller stories have a multitude of benefits over larger stories, such as less complexity and therefore less risk, but they also tend to be easier for your team to understand. But despite these benefits, some teams resist the shift towards smaller stories. However, feeling the pain first hand of losing a significant amount of points in a Sprint simply because a story is almost complete is an excellent way to incentivize your team to look for seams to break their largest stories into smaller stories which can be delivered in the space of an entire Sprint.

Seeing the Bigger Picture

When following this approach don't be surprised if you hear complaints from your stakeholders that carrying over so many points from Sprint to Sprint is likely to skew your team's velocity. For example, depressing your team's velocity in the first Sprint only to artificially inflate it in the next Sprint.

However, this is an excellent opportunity to shift the conversation with your stakeholders from focusing on your team's velocity at the individual Sprint level to instead thinking of your team's velocity in aggregate across several Sprints. Not only will this shift in thinking better equip your organization to plan for the long term, but the variations in velocity from Sprint to Sprint will better average out across multiple Sprints.

Moreover, just as with your team, this is also an excellent opportunity to begin shifting your stakeholders' attention away from points closed and towards value delivered.

Seizing the Opportunity to Reevaluate Priorities

As a final note, I want to emphasize that no story should ever simply be rolled into the next Sprint without the Product Owner first taking a moment to consider whether continuing to invest in that story is even still the best use of the team's time.

A Product Owner is accountable for ensuring that the organization's investment in the team is made so in a way that will yield the most significant return for that organization. To this end, when planning the coming Sprint, the Product Owner should be considering whether each story selected is truly the highest value item on which the team should be working.

This means that even though a story might have been considered the best use of the team's time at the beginning of the last Sprint, that doesn't necessarily mean that will remain true in the next Sprint. Perhaps higher value work has emerged since the previous Sprint was planned or perhaps there has been a development in the marketplace which has deemed that story no longer necessary.

Or, perhaps the story in question is still important to the organization, but upon closer inspection, the Product Owner realizes that the work the team has done thus far is enough to add the value needed. As a result, the remaining work is simply no longer necessary or at least can be deferred.

Whatever the outcome, the Product Owner should always take the opportunity to evaluate whether continuing to invest in an in-progress story is truly the best use of the team's time or if there is now more impactful work that the team should be pursuing. In either case, the key is to avoid falling into the fallacy of sunken cost and simply continuing to pursue a story to completion simply because work on that story has already begun.

Continuously Inspecting and Adapting

Remember that every Sprint is an opportunity to inspect and adapt the work the team is pursuing. Part of that process is continuously inspecting the work that the team is currently tackling and adapting that work if it’s deemed to no longer be the best use of their time.

By regularly re-evaluating the stories the team is rolling from Sprint to Sprint and shifting the focus from “staying busy” to actually delivering value, the entire team can help to ensure that they are in a position to deliver the most value for their users as well as their organization.

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.

Continue Reading
No Comments on How to Handle Stories That Aren’t Completed in a Single Sprint
5 min read
Uncategorized

Creating Great Sprint Goals

5 min read
No Comments on Creating Great Sprint Goals
5 min read

This post originally appeared on the PivotalTracker blog. Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do…

This post originally appeared on the PivotalTracker blog.

Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do you see a theme that ties each of them together?

Too often, the set of stories that teams select for their Sprint has no overarching theme or focus. In fact, while these stories may be individually valuable, at times their selection can appear almost random.

But high-performing agile teams begin each Sprint Planning session by defining an overarching goal that they would like to accomplish by the end of that Sprint. This shared planning helps the team select a cohesive set of stories that will help them reach that goal. However, there’s also another advantage to crafting a great Sprint goal.

A great Sprint goal helps your team understand why it’s embarking on the Sprint in the first place. This context not only better positions your team members make more informed decisions during the sprint, but it also gives them guidance in the event that they need to adjust their Sprint plan during the Sprint to react to unexpected developments.

How Are Great Sprint Goals Crafted?

Crafting great Sprint goals is easier than you may think. The best time to craft your Sprint goal is at the beginning of each Sprint Planning session. Doing this at the outset will help set the context for what the team will be tackling over the next Sprint and better equip your team to select the stories that will support that goal. While the process of crafting a sprint goal is typically led by the Product Owner, ideally the entire team should be involved in this process. This will create a shared understanding of the goal that the team is trying to accomplish and create buy-in towards that goal.

When crafting your Sprint goal, remember that the best goals are specific enough that there will be no ambiguity as to whether or not the team accomplished the goal, but also are not so specific as to constrain the team’s flexibility to adapt their Sprint plan in pursuit of deciding how to best achieve that goal.

For example, Increase the number of social login options available to the user is a great example of a Sprint goal, since it defines a clear direction but leaves the flexibility to the team to decide how to best achieve that goal.

As another example, while Improve the long-term maintainability of the reporting framework is a great Sprint goal, Reduce technical debt is not. This is because while the former gives the team a clearly defined and high-level objective to aim at, the latter is vague and tough to quantify. This can make it hard for the team to clearly decide at the end of the Sprint whether or not they actually achieved their goal.

Planning From the Top Down

So where do Sprint goals come from, you ask?

When first creating a Sprint goal, many teams are tempted to just select stories as usual during their Sprint Planning session and then simply derive a Sprint goal from any common themes they spot in those stories.

While at first, this approach may seem better, it often leads to vague Sprint goals that merely describe the lowest common denominator found in every story selected for that Sprint. As a result, it can be hard to quantify whether these goals were achieved at the completion of the Sprint or even whether completing the goal actually yielded any value to the organization and the overarching release.

The best Sprint goals are often derived from your overarching release goals. Specifically, if you’ve defined a high-level goal for your release, you can begin by decomposing that goal into roughly Sprint-sized chunks, of which each chunk will become the starting point for a Sprint goal. Don’t worry if you’re not sure how to decompose your high-level goal into Sprint-sized chunks as this is a great opportunity to involve your technical team early so they can help you understand how large each chunk of work is likely to be. Not only will this increase the likelihood that your initial chunks of work fit together well, but the early involvement of your team will also help to create a shared understanding of what the goals of the release are, as a whole.

Seeing the Bigger Picture

Crafting clear Sprint goals helps your team understand how the work they are doing in each Sprint is a part of something bigger. Helping your team see the bigger picture not only equips them to make better-informed technical decisions during the Sprint, but it also gives them valuable insight into the overall vision for their product as well as how the work they are doing today contributes to that vision.

Curious to try this for yourself? Invite your team to collaborate with you during your next Sprint Planning meeting to set a Sprint goal that moves your team closer to success. Then, after the end of that Sprint, let us know in the comments below how it went! I’d love to hear how this worked for you and your team!

Want to learn how to deliver the work that matters most to your users? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master or Product Owner and to 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.

Continue Reading
No Comments on Creating Great Sprint Goals
7 min read
Uncategorized

How Many Teams Can A Scrum Master Work With?

7 min read
No Comments on How Many Teams Can A Scrum Master Work With?
7 min read

As someone who spends a majority of his time working with Scrum teams and Scrum Masters, one of the most common questions that I’m asked is “how many teams can…

As someone who spends a majority of his time working with Scrum teams and Scrum Masters, one of the most common questions that I'm asked is “how many teams can a Scrum Master work with?”.

However, despite how common this question is, there is no simple answer. The Scrum Guide, often our first stop in our journey for questions about the Scrum framework, is silent on this matter. And while a quick internet search will turn up plenty of opinions on the subject, those opinions are usually based on the commenter's unique experience in their specific situation rather than applicable to a wide range of situations.

The fact is that there is no universal answer to this question. The right answer for your organization is going to depend on many factors, such as the skill of your Scrum Master, whether or not that Scrum Master is focused on the Scrum Master role full-time, the maturity of the team that the Scrum Master is assigned to, and of course, the maturity of the overall organization.

However, despite the uniqueness of each situation, there are some rules of thumb that seem to apply in the majority of situations. We can use these rules as a starting point, and then adapt our approach based on what we discover about our specific environment.

Laying the Ground Rules

As a general rule, a skilled Scrum Master can work effectively with 2 to 3 teams. However, there are a few caveats with this generalization.

The first caveat is that I'm assuming that this individual is focused on the Scrum Master role full-time. This means that the individual is not splitting their attention between the Scrum Master role and another role on the Development Team, such as coding or testing. Individuals described by the latter statement can only work with one team at a time: their own.

The second caveat is that I'm assuming that the Scrum Master has a reasonable level of experience and has grown their skills while acquiring that experience. While I'm hesitant to recommend a specific amount of experience, 2 to 3 years of experience across various teams seems to give Scrum Masters the opportunity to grow the skills they need to be successful in a majority of situations. In any case, you should be wary of assigning more than one team to a first time Scrum Master.

The Dangers of the Extremes

Let's dive a bit deeper into the recommendation of 2 to 3 teams to understand better from where this idea comes. First, let's look at the extremes.

For a full-time Scrum Master who is reasonably skilled, working with only a single team is often not enough to keep that individual from becoming bored with their role.

In some cases, this will simply lead to the Scrum Master becoming disengaged and neglecting their responsibilities to the team and their organization. However, in other cases, the Scrum Master may try to invent responsibilities to fill their excess time, often creating low-value work for themselves and, by extension, their teams. The number of metrics that a Scrum Master has conceived of for their teams is often a good indicator of this situation. While some metrics can provide value to the overall planning and tuning of a Scrum team, metrics covering every square inch of available wall space are often a sign of a Scrum Master with too much time on their hands.

Now let's take a look at the other extreme. Generally speaking, when a Scrum Master is asked to work with more than 3 teams they often find themselves spread too thin to add value to any of those teams.

To be truly effective with their teams a Scrum Master must be embedded in those teams. This embedding not only gives the Scrum Master the opportunity to spot friction points or opportunities for improvement, but it also helps the Scrum Master build empathy for those teams by experiencing first-hand the trials and tribulations that the rest of the team experiences on a daily basis.

If a Scrum Master is spread between any more than 3 teams, then it's highly unlikely that they will spend enough time with those teams for those things will happen.

Finding the Sweet Spot

As a result, the sweet spot for Scrum Masters who work with multiple teams is usually between 2 and 3 teams.

Giving a Scrum Master the opportunity to work with multiple teams helps that Scrum Master grow in their craft more quickly, as they have the opportunity to deal with a wider range of challenges as well as see different perspectives on how each team implements the Scrum framework.

But there's also another, more subtle benefit. When a Scrum Master works with multiple teams, they're also more likely to shift their perspective from that of an individual team towards a more holistic view of their entire organization. As a result, the Scrum Master is better able to seek out opportunities to apply the Scrum framework in their broader organization, therefore improving the lives of more teams than simply their own.

Diving Deeper Into a 2 to 3 Team Scenario

Now that we have a better understanding of why 2 to 3 teams may be the sweet spot for a Scrum Master working with multiple teams let's unpack of the details of each of these scenarios to understand better how each may work.

More often than not, a Scrum Master working with 2 teams is the sweetest of the sweet spots. In this scenario, the Scrum Master can spend significant time with each team and truly immerse themselves into the challenges those teams are facing.

Ideally, in this scenario one of the teams will be more mature than the other, which allows the more mature team to operate with more independence giving the Scrum Master more time to focus on the team that's more likely to struggle. In addition, this also provides the Scrum Master the opportunity to consider the juxtaposition of the two teams which can inspire new lines of thought or experimentation.

Expanding on the concept of working with teams of different skill levels, in a 3 team scenario ideally one, if not two, of those teams, are already mature and relatively independent. This allows the Scrum Master to serve in more of a support role for the two maturing teams which frees them to focus on the immature team. However, as the move from 2 teams to 3 teams can be more challenging than you might originally expect, having a highly-skilled Scrum Master in the mix is even important in this scenario.

Note that in both the 2 and 3 team scenarios, the Scrum Master is intentionally electing to spend less time with their more mature teams. While at first, this might surprise you, remember that at all times a Scrum Master should be preparing their teams to operate more and more independently, therefore, lessening their dependence on their Scrum Master. Intentionally lessening their involvement with their teams, while still remaining available to provide support where necessary, is a great first step in this direction.

Finding Your Own Sweet Spot

Remember that above all, the scenarios that I've outlined above are nothing more than guidelines. Every organization is different, every team is different, and most importantly, every Scrum Master is different.

While I'm hopeful that this guidance may be of some help in your own planning for the Scrum Master role remember that, as with all things agile, the only sure path to success is through constant experimentation and learning. You'll need to experiment in your own organization to find the optimal arrangement for your teams as well as expect the most optimal arrangement to shift over time as your teams evolve.

The guidance above should be considered nothing more than a starting point. Only your teams can tell you which approach will work the best in your organization.

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.

Continue Reading
No Comments on How Many Teams Can A Scrum Master Work With?
5 min read
Uncategorized

Coaching Your Product Owner As A Scrum Master

5 min read
No Comments on Coaching Your Product Owner As A Scrum Master
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.

Continue Reading
No Comments on Coaching Your Product Owner As A Scrum Master
5 min read
Uncategorized

Should A Manager Be A Scrum Master?

5 min read
No Comments on Should A Manager Be A Scrum Master?
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.

Continue Reading
No Comments on Should A Manager Be A Scrum Master?
5 min read
Uncategorized

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

5 min read
No Comments on Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning
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.

Continue Reading
No Comments on Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning
5 min read
Uncategorized

Writing Great User Stories For Developing APIs

5 min read
No Comments on Writing Great User Stories For Developing APIs
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.

Continue Reading
No Comments on Writing Great User Stories For Developing APIs
6 min read
Uncategorized

Plotting The Scrum Master’s Career Path

6 min read
No Comments on Plotting The Scrum Master’s Career Path
6 min read

The growing demand for Scrum Masters has created an influx of new Scrum Masters into the role. And while most of those Scrum Masters have loved their new career, many…

The growing demand for Scrum Masters has created an influx of new Scrum Masters into the role. And while most of those Scrum Masters have loved their new career, many have found themselves wondering what’s next? Even if you’re happy in your role it’s normal to wonder what opportunities might exist beyond that role. In fact, you may find yourself wondering if there even is a Scrum Master's career path. If this sounds familiar then you’ll be happy to know that there is a career path for Scrum Masters…it just might not look quite like you expect.

Skilled Scrum Masters show an incredible amount of versatility, often adjusting their approach to meet the specific needs of their teams. This versatility makes the Scrum Master role an ideal jumping off point to a myriad of other career opportunities. But finding the right career path for you primarily depends on what facet of the Scrum Master role appeals to you most.

Becoming An Agile Coach

Often Scrum Masters are so pleased with the positive effect that an agile approach has had on their teams that they want to bring this approach to their entire organization. If this sounds like you and you’d like to be catalyst for changes inside of your broader organization than becoming an agile coach may be the right path for you.

To be successful, you’ll need to develop the ability to coach at higher levels in the organization than you do as a Scrum Master…often at the executive level. You’ll also want to familiarize yourself with concepts such as business agility to better explain how an agile approach can benefit even the non-technical functions in your organization as well as become well-versed in change management strategies since introducing a significant change to a large organization is not for the faint of heart. Finally, it can also be beneficial to broaden your exposure to agile methodologies beyond Scrum so you have a wider variety of tools at your disposal in your agile toolbox.

Making The Move to Product Owner

Sometimes Scrum Masters find what really appeals to them about the Scrum framework is how it enables them to deliver better products to their users. If you find yourself most fascinated by the end product your team is creating as well as understanding whether that product is actually meeting your users’ needs then the Product Owner role may be the right move for you.

Product Owners who have a background as a Scrum Master can be incredibly empowering to their teams. This is due not only to their deep knowledge of the Scrum framework, but also to the perspective that they’ve gained during their role as a Scrum Master. This perspective can better equip Product Owners to understand exactly what their Scrum teams need from them. This insight can be incredibly valuable as you work to find the right balance between setting a clear direction for your team but also giving them the freedom to identify better solutions as they emerge.

However, remember that each of the 3 roles on a Scrum team are defined as peers. Therefore you should be careful not to consider a move to the Product Owner role as a promotion above the Scrum Master role. In healthy teams, a move between these two roles would simply be considered a lateral move with the benefit of adding another facet to one’s Scrum experience.

Becoming A Manager

Often when agilists think of managers we picture pointy-haired Dilbertesque bosses forcing mundane tasks on their employees without a care for the well-being of those employees. However, while there certainly are managers that fit this description, generalizing all managers in this way would be unfair.

There are many excellent managers who regularly demonstrate a high-degree of empathy for their employees, a well-refined sense of emotional intelligence, and a sincere desire to help their employees grow both personally and professionally.

If this sounds like a path that may appeal to you then many of these same skills that you developed as a Scrum Master will transfer well. Combine this with the team facilitation skills that you’ll also develop as a Scrum Master and you can be well on your way towards a fruitful career as a manager.

Furthering Your Investment In The Scrum Master Role

Finally, it’s important to understand the Scrum Master role doesn’t always have to be a stepping stone into a new career. Many Scrum Masters have found that they enjoy the role so much that they desire nothing more than to simply spend their career as a Scrum Master. In fact, many organizations are now changing how they think about this role to help enable these types of individuals.

For example, many organizations have introduced a Scrum Master career ladder often culminating in a Senior Scrum Master position. As Scrum Masters progress along this ladder they gain more and more responsibility by working with multiple teams, working with teams at different skills levels in their agile journey, acting as an agile advisor to their broader organization, or even serving as a mentor to more junior Scrum Masters.

In addition to this role, many organizations who have endeavored to scale Scrum also have created roles specifically to enable this scaling process. Sometimes referred to as a Chief Scrum Master, this role is often tasked with assuming responsibility for the entire scaled Scrum implementation as well as for identifying and addressing any scaling dysfunctions that may occur as the organization grows.

If you find that you simply really love the act of being a Scrum Master, then either of these opportunities may appeal to you.

Finding The Right Path For You

Becoming a Scrum Master can be the first step in a long and rewarding career that can offer many different career paths over time. Whatever path is right for you, you can be sure that the skills and relationships that you’ll develop as a Scrum Master will serve you well on that journey.

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.

Continue Reading
No Comments on Plotting The Scrum Master’s Career Path
10 min read
Uncategorized

Finding The Right Scrum Master Job

10 min read
No Comments on Finding The Right Scrum Master Job
10 min read

The surge in demand for Scrum Masters has led to a wealth of available job opportunities for motivated Scrum Masters. This means that if you’re a budding Scrum Master anxious…

The surge in demand for Scrum Masters has led to a wealth of available job opportunities for motivated Scrum Masters. This means that if you’re a budding Scrum Master anxious to break into this new career, or an experienced Scrum Master just looking for a new challenge, then this is a great time to be on the market. But with all of the Scrum Master jobs available, how do you know which job is right for you?

One of the best indicators of whether or not a Scrum Master job is right for you is how an organization’s view of the Scrum Master role aligns with your own view of the role. While the responsibilities of the Scrum Master role are clearly defined in the Scrum Guide, the lightweight and non-prescriptive nature of the Scrum framework often leads to many organizations taking wide latitude with how they interpret this role. And this interpretation may or may not align with your own interpretation.

Luckily, there are four simple questions that you can ask to help determine if you and a new organization are a match made in heaven, or if you may be in for a nasty surprise your first day on the job.

Question 1: How Do You Measure A Scrum Master’s Success?

One of the most common surprises you might find with a new Scrum Master position is when the organization views the Scrum Master role simply as a rebranded project manager. In these instances, you may find that your goals for your new position don’t align with your organization’s goals.

One of the best ways to identify if such a discrepancy exists is by asking how the organization measures the success of their Scrum Masters. Organizations who are simply treating the Scrum Master role as a rebranded project manager will often cite criteria as to whether or not the Scrum Master’s team is delivering the work expected of them on-time and in-budget, how well the Scrum Master is pushing the team to meet previously agreed upon deadlines, and if the Scrum Master is increasing the team’s velocity sprint-after-sprint. While the organization may feel that they find value in each of those criteria, many of those criteria still carry the smell of a command and control approach to software delivery, not to mention that they also mistakenly equate a team’s busyness with the value that they produce.

In contrast, organizations who have a healthier perspective on the Scrum Master role might cite criteria that could indicate that the Scrum Master is enabling their team to improve as a unit. For example, is the Scrum Master actively working with the broader organization to help them understand how they can better support the team, is the team becoming more self-sufficient and self-managing, and is the team’s overall throughput improving and their velocity stabilizing. Each of these criteria can indicate a Scrum Master who is actively improving the way their team operates and laying the groundwork for sustainable improvements to how their team delivers value to their organization.

But to truly know how deeply the organization understands this difference, you should also pose this same question to the existing Scrum Masters in the organization. Most large organizations will already have several Scrum Masters on staff. And, if there are already Scrum Masters in the organization, then they should most certainly be part of the interview process.

This is a great opportunity to also ask those current Scrum Masters how their success is measured in the eyes of the organization. If the answers given by the Scrum Masters differ significantly from the answers given by the organization, then this could be an indication that the organization hasn’t made their expectations clear to the Scrum Masters and that they don’t truly understand how they are being measured.

Question 2: What Is Your Career Path For Scrum Masters?

Another indicator of whether or not an organization is the right fit for you can be how they view the career path of Scrum Masters. But to know this, you first have to understand what you ultimately want from the Scrum Master role.

The versatility of the Scrum Master role makes it uniquely well-suited to serving as a jumping off point to other longer term career aspirations. For example, if you desire to broaden agile adoption across your organization, then the deep agile knowledge and facilitation skills that you gain as a Scrum Master can serve as an excellent step towards becoming an agile coach. On the other hand, if you find that you are most interested in the outputs that your team produces and how those outputs ultimately provide value to your stakeholders, then a career in product management may be in your future. Or finally, if you discover that you simply enjoy working closely with development teams and enabling them to continuously push the envelope of what they’re capable of, then simply continuing to pursue a mastery of the Scrum Master’s craft may be your goal.

Regardless of your long-term career aspirations, you should confirm that the career ladder available at your new organization will enable those aspirations. Often this can be learned by simply asking what an organization’s career path is for Scrum Masters.

If you desire an eventual move into product management, then you might seek an organization who encourages Scrum Masters to move laterally into other parts of the organization, such as business analysis or product management. On the other hand, if your longer-term aspirations are to become an agile coach, then you might seek an organization whose career ladder gradually increases the responsibility of Scrum Masters into broader areas of the organization until those individuals are acting as executive level coaches. Or, if you’re one of the many Scrum Masters who simply loves the role of Scrum Master and wants to continually refine their craft, then you might seek an organization with multiple levels of the Scrum Master role. These Scrum Master career ladders, which often culminate in titles such as Lead Scrum Master or Senior Scrum Master, are designed to a grow a Scrum Master’s skills by gradually increasing their responsibility by giving them responsibility for more teams, teams who are new to or who are struggling with their agile adoption, or even responsibility for training and mentoring more junior Scrum Masters in their organization.

Whatever your long-term career aspirations are, you’ll want to be sure to find an organization that will enable and support those aspirations long into the future.

Question 3: What Is A Day In The Life Of A Scrum Master?

One of the best ways to understand how the organization views the Scrum Master role is simply to ask the organization’s other Scrum Masters.

Asking each Scrum Master to describe a typical day can give a lot of insight into the expectations of that organization’s Scrum Masters. For example, do the Scrum Masters speak mostly of removing impediments for their team or do they seem to be more focused on teaching their team to remove these impediments for themselves. Or, do the Scrum Masters speak of leading the various Scrum events for their team or do they position themselves as a facilitator who helps their team get the most from these events. Listening to not only what activities the Scrum Masters describe, but also for subtle cues in how they describe them can be very revealing of the Scrum Master’s true role in the organization.

And, as with previous questions, turning this question back on the organization can reveal how well the organization understands how the Scrum Master role functions in their organization. If you find that the organization’s description of the daily activities of a Scrum Master differ significantly from what the Scrum Masters describe, then this may be an indication that the organization doesn’t truly understand the challenges their Scrum Masters are facing each day.

Question 4: What Are You Looking For In Your Next Scrum Master?

Finally, if you are fortunate enough to meet other Scrum Masters in the organization during the interview process, then you can also use this opportunity to gain insight into how well those Scrum Masters are currently functioning as a team.

For any lasting change to take effect in an organization, there must be multiple Scrum Masters acting in concert to enact that change. This not only enables those Scrum Masters act as a chorus of guidance to the organization, rather than as a single lonely voice, but it also allows each of those Scrum Masters to reinforce that same guidance across multiple teams in the organization.

But in order for this to happen, it takes more than just multiple Scrum Masters in the same organization…those Scrum Masters must be acting in a coordinated effort. One of the best ways to understand how well-coordinated this effort is is to ask the other Scrum Masters what they are looking for in their next Scrum Master.

Asking this question helps you understand how introspective the current team of Scrum Masters are about their strengths and weaknesses. A mature team of Scrum Masters will be very introspective which will allow them to identify gaps in their skills across the team. For example, the team may understand that while they have a strong grasp of the Scrum framework, they lack significant experience with other agile methodologies like Kanban. Or while the members of the team may feel very comfortable coaching at the team level, they may lack the skills to coach effectively at the executive level.

A mature team of Scrum Masters will be introspective enough to identify opportunities for improvement and will be actively seeking to fulfill these opportunities gaps with the next addition to their team.

Making Your Next Move The Right Move

Considering any change in employment can be a stressful time. This is especially true when that change involves a role that can be as widely interpreted as the Scrum Master role. But by understanding what you truly desire from your next opportunity, as well as asking the right questions to help you learn whether or not your new organization will support those desires, you can greatly increase your chances of making your next change a successful one.

Do you want to learn the skills that you'll need to ace your next Scrum Master interview? Check out my course series, Using the Scrum Framework, 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.

Continue Reading
No Comments on Finding The Right Scrum Master Job
6 min read
Uncategorized

Can the Length of Your Iteration Change in the Middle of Your Project?

6 min read
No Comments on Can the Length of Your Iteration Change in the Middle of Your Project?
6 min read

This post originally appeared on the PivotalTracker blog. Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an…

This post originally appeared on the PivotalTracker blog.

Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an iteration-based approach provides many advantages to teams. But while there’s little argument concerning the value of iterations, finding the right iteration length for a team is no small feat.

But, even after finding the right iteration length, some teams start to wonder if the length they once thought was so perfect is still the right choice for them. Perhaps they’re lured by the promise of the greater efficiency of longer iterations, or the greater responsiveness of shorter iterations call to them like a siren’s song. Whatever the reason, it inevitably begs the question: can a team change the length of their iterations in the middle of a project?

If your team happens to be pondering this same question, then you’ll be happy to know that the answer to this question is a resounding, “Yes!” It’s completely acceptable for teams to change the length of their iteration in the middle of their project and it actually happens more often than you might think. But while changing iteration lengths in the middle of a project can be done, it’s not a decision that should be taken lightly. Luckily there are a few things that can improve your odds of success if your team is considering heading down this path.

Preparing Your Team for the Change

Any change to how your team works will require time for them to absorb. This is true whether that change is the adoption of a new piece of the team’s technology stack, a new technical practice, or even a new team member. Even if the change is ultimately a positive one, don’t be surprised if your team’s output dips a bit while they become accustomed to this new way of working. This is especially true when changing your iteration length, since you’re fundamentally altering the timebox in which your team works.

The first thing you’ll need to do to prepare your team for this change is to help them understand how their planning activities will also need to change. For example, your team is probably conducting a planning session at the beginning of each iteration to select and plan their work for the upcoming iteration. And they’re also probably holding a review session at the end of each iteration to review their work and ensure that they’re on track to delivering what their customer needs.

If you are shortening the length of your iteration by half—e.g., from two weeks to one week—then you can expect that the duration of the accompanying planning and review sessions will also be shortened by half. For this to be successful, you must make sure your team understands that this shortened planning duration means that they’ll need to be more efficient during those sessions in order to accomplish everything they need to within the time allowed. A team that shortens its iteration length but continues to spend just as much time in planning sessions gains nothing and actually loses efficiency as now a smaller percentage of their time is spent actually producing value.

On the other hand, if your iterations are becoming longer, then you’ll need to prepare your team for the reality that they’ll now need to spend correspondingly more time in their planning and review sessions. For example, imagine that your team is currently working in two-week iterations but decides that three-week iterations are a better fit. If your team is currently spending four hours on the first day of each iteration planning their work for the next two weeks, then you’ll need to prepare them to spend roughly six hours planning their work on the first day of every iteration moving forward. While most teams will, at least superficially, understand the need for correspondingly longer planning sessions to accommodate the larger undertaking of work, *understanding* a six-hour planning session and *participating* in a six-hour planning session are two entirely different things.

Predicting the Result of the Change

But once you’ve prepared your team for this change, how do you understand the effects it will have on your project? A team’s velocity is often treated as one of the major indicators of a project’s success. And while we understand that velocity is not our goal, tracking a team’s trend in velocity over the past few iterations can be a powerful tool for forecasting the capacity that we can expect from that team in the future. But how can we predict the change in our team’s velocity after we’ve altered their iteration length?

It can often be tempting to simply extrapolate a team’s change in velocity based on the corresponding change in the team’s iteration length. For example, if your team has an average velocity of 50 points per iteration using two-week iterations, then it would stand to reason that that same team should produce 100 points per iteration using four-week iterations, right?

Maybe. Or, maybe not. Extrapolating a team’s new forecasted velocity based on the change in their iteration length may be a good place to start, but the actual effect of that change is rarely that simple.

A lot of factors can affect a team’s velocity from iteration to iteration, and the actual result of a change in iteration length may not be reflected in that team’s velocity for several iterations. This means that while your team’s velocity *will* change as result of a change in iteration length, *how* it will change will be tough to predict. For this reason, you’ll need to be prepared to expect the unexpected for the first few iterations under the new length as well as be prepared to account for this change in velocity in your longer term project planning.

Making the Most of the Change

While you won’t want to alter your team’s iteration length on a regular basis, the occasional change can be not only successful but even a very positive change for your team.

However, this change shouldn’t be taken lightly and your team will need your help to make it successful. By preparing your team for a change in iteration length using the tips above, you can help ensure they make the most of this new new change to their workflow.

Want to learn more about how to make agile work with your team when things don't go as expected? 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.

Continue Reading
No Comments on Can the Length of Your Iteration Change in the Middle of Your Project?

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