4 Ways Attention to Detail Might Be Hurting Your Team

Attention to detail is a pattern of behavior that many teams hold in high esteem. Job descriptions, résumés and LinkedIn endorsements often emphasize attention to detail as a foundational component for any capable team member.

It’s easy to understand why teams value attention to detail ‒ almost everyone experiences the consequences of missed details at some point, and attention to detail can prevent these damaging experiences from happening.

Missed details can lead to inaccurate cost forecasting, underestimating work, a dysfunctional product and a seemingly endless list of other problems.

However, attention to detail can sometimes have a negative effect on your team if performed without proper guidance, and yet I’ve never heard anyone list “inattention to detail” on their résumés or as a skill on a job website.

I would posit that the world needs a few less people striving to be difference makers, and a few more up-and-coming indifference makers.

So, when is it better to be inattentive to detail? As the proverb goes, the devil is in the details. Here are five common examples of when attention to detail can have a negative effect on your team.

When It Adds Work That Isn’t Needed

Attention to detail is only as important as the details themselves. If you’re focusing your efforts on inconsequential details, you may be adding work to your team that isn’t needed.

If your team is a finite resource, this can be an unwelcome burden to contend with.

For example, if you’re in charge of a marketing team, you may be tempted to spend a lot of time carefully tailoring every mass email, Facebook post and tweet. However, if you don’t have any users following you on Twitter and it’s going to be an uphill battle to acquire additional followers, sacrificing some quality on Twitter by not proofreading every tweet might help reduce a lot of work for your team without resulting in much negative impact at all.

Take a look at your team and consider if there is any work being regularly performed with too much attention to detail, where less effort can save a lot of time without losing a lot of value.

When It Distracts From More Important Work

While paying attention to some details is completely unnecessary, other details may be valuable, albeit less valuable than others.

For example, it’s tempting to want to fix all existing bugs in a piece of software. After all, chances are someone is being affected or could be affected by bugs in your software and have a negative experience as a result.

However, not all bugs are created equal -- some bugs may be affecting a large section of customers while others may affect only small segments. For example, your software may have bugs that appear only in IE7, but if only 0.5 percent of your users use this browser, spending time fixing these bugs is time you could have spent fixing higher priority bugs, adding features to deliver more value to larger sets of customers or adding optimizations that reduce costs and deliver a better user experience for all customers.

When It Delays the Frequency of Shipping Increments

Sometimes, paying too much attention to detail tempts people to delay the shipping of increments, which is contrary to the goals of agile.

While it’s true that some details like feature requirements should hold up shipping an increment, scope creep that involves unnecessary details should not prevent your team from delivering. Many times, these minor details can be bumped to the next iteration, especially if the choice to not work on them doesn’t have a significant effect on your users.

In general, it’s better to get the increment out the door and collect feedback from users to readjust priorities and understand what work should be completed next. You may find that after your release the iteration, the users have more urgent needs that they communicate back to your team and would rather you not spend your time working out those smaller details.

When It Makes It Harder to Identify Problems

Along those lines, when details hold up shipping increments it can make it harder to identify problems.

For example, if the original task requirements were not fully explained or were missing some details during scoping, the sooner you ship the increment and collect feedback, the sooner you’ll uncover the gaps or items that were built based on incorrect input.

Getting bogged down in details that don’t have much of an impact can often obfuscate problems in your work by delaying iterations, so be sure to critically ask yourself if the detail is worth focusing on before you allow your current iteration to drag on down a potentially problematic path.

Putting It All Together

Attention to detail is very important in many cases, but not all cases. Similarly, inattention to detail shouldn’t be applied in a blanket fashion across all cases.

However, as illustrated above, you may want to analyze your current processes and see if there are gains to be had by eliminating attention to detail when it adds work that isn’t needed, distracts from more important work, delays shipping increments unnecessarily or prevents you from catching and addressing problems early on in the product development lifecycle.

Ready to be an indifference maker? Take a look at your current processes and let me know how your team could benefit from being less attentive to details in the comments section below.

Agile Strategies to Explain Doing Less Work

It might seem counterintuitive to convince people to do less work, but reducing work is actually one of the most effective ways to deliver the most value to your customers as quickly as possible. In fact, the authors of “The Agile Manifesto” suggested minimizing work in their Twelve Principles of Agile Software which states, “Simplicity--the art of maximizing the amount of work not done--is essential.”

However, it can also be difficult to convince someone that they shouldn’t take on work that they see as necessary to provide a specific value. I previously wrote about how to convince people to de-prioritize work, but there is some work that just shouldn’t be done at all.

To help navigate this discussion, I’ve created a quick overview of common scenarios where pursuing work can often be a bad idea and how you can explain to someone that the work they suggest should not be pursued. The conversation can become uncomfortable at times, but remember that your organization stands to better itself by following your agile-minded leadership. The following are just a few examples of commonly requested work that should almost always be avoided. 

Work That Adds the Wrong Value

Sometimes, adding value isn’t a good thing. For example, it might not be sustainable if it costs a lot to maintain over time. It may also force your team to deviate from your core roadmap that delivers more value to your customers. There are many other reasons why work can’t be justified simply by “it adds value,” but a lot of people naturally see value as a good thing by default.

For example, someone might suggest that Toyota should be selling Prius models that include a turbocharger. After all, Prius drivers might want to go faster considering the acceleration and speed limitations of their car.

However, the smart folks at Toyota probably realized that the parts, labor and maintenance costs would far outweigh any fuel efficiency gains or eco-friendly image – all of which are driving reasons behind why people buy a Prius. In this case, the added value of the turbocharger isn’t worth the cost and isn’t really anything the target customer asked for or wants.

In cases like this, ask the person requesting the work what the costs are related to the work, and collaborate with them to identify the ongoing costs needed to maintain that work. Also determine if the work is suitable to your target user base and if it makes sense in the context of your overall product roadmap. 

Work That Solves Problems That Don’t Exist for the User

When people request work that solves a problem that doesn’t exist for the user, they usually aren’t thinking of the problem as nonexistent. Unfortunately, this is more common than anyone would like to admit, since people often act based on their own personal situation or their past experiences rather than user research.

For example, a team member in an early-stage startup that manufactures bicycles might suggest that the bicycle should be able to allow the rider to go up stairs in offices and other buildings in an automated way in order to be compliant with disability laws.

While improving accessibility for all individuals is a noble endeavor and should be at least considered in any product, it might not be economically feasible for the startup to pursue disability law compliance during its early stages, and it likely isn’t even required of bicycle manufacturers.

In this case, there is no legal requirement in place and the typical user of the bicycle is understood to have some level of expectation around whether it can automatically climb stairs. This is a problem that may not exist for users of this product, since there are other products that can help disabled individuals ascend stairs in a more efficient and effective way.

In addition, it may be more economical for a third-party manufacturer to create custom enhancements or focus specifically on Adaptive Cycling users, rather than each bicycle manufacturer taking on the problem independently. Adaptive bicycles could also make up a future product line as the startup matures. 

In cases like this, ask your colleague for documentation that the problem exists, which in this scenario might be legal compliance requirements or regulations. Solving problems that do not exist can be very costly both in terms of the work done and the work that could have been done instead. 

Work That Creates Duplicate Efforts

Duplicate efforts can become a significant waste in workflow if not properly identified and avoided. This applies to all areas of creating, supporting and selling the product, not only the product development process.

For example, you may have a backend interface that allows your internal team members to generate reports, as well as a separate customer-facing reporting interface that allows customers to generate reports. In that case, you would have two completely separate reporting engines that have overlap in the data they’re trying to access and the reports they’re trying to generate. 

Instead, you may want to reduce duplicate efforts by moving all reporting to the customer-facing interface, but restricting access to internal-only reports for your team members exclusively. This way, you can enjoy the benefits of focusing all of your reporting-related time and effort on building and optimizing one reporting feature rather than two separate ones. 

In cases where people request duplicative work, they often don’t realize there is duplication involved and they may not see the whole picture of your product, internal tools or other aspects. To help them understand, explain where the duplication exists and how eliminating duplication will produce significant advantages. Be sure to rationalize your plan by explaining the cost involved and how the benefit will outweigh that cost, assuming it does. 

The Possibilities are Endless, but Your Resources Aren’t

In many cases, team members can stop at the initial stages of analysis where they see that a specific task will accomplish a specific outcome. However, there are several possible detractors that are often not identified, such as the cost to complete the task, alternative work that could be more valuable or potential problems with scaling such as ongoing cost and upkeep.

Your agile team is a limited resource with limited manpower and limited time (assuming that building a time machine is still far off on your product backlog). Before agreeing to send work to them, consider the areas mentioned above and any other reasons why simplifying the workload per agile best practices will help ensure the most value is delivered to the customers or users as quickly as possible.

These are just some of the common examples that may come up from time to time, so feel free to share any that you regularly encounter in the comments section below.

#NoEstimates: Crazy Talk, or Agile Compatible?

A couple years back, I started hearing about an interesting movement in the software and web development community called #NoEstimates. At the time, I was fresh out of CSPO and PMI-ACP certifications, and I naturally started wondering about this movement that was too new to be taught by the courses I took to earn those certifications.

I had colleagues who were adamant that we avoid estimates in most cases, while others insisted it was insane to suggest that accurate estimates were not always necessary or possible. Before forming my own opinion, I decided to examine as many sides of the discussion as I could and read up on the thoughts of various writers and experienced professionals in the community.

What I found were well-reasoned arguments on both sides. However, one thing that bothered me was that people who did not favor implementing a strictly defined agile framework didn’t tend to want strict estimations either, while those who wanted to implement a more elaborately defined agile framework also tended to support formal estimates.

It made me wonder – can #NoEstimates and agile coexist in the same team? Did being agile and Scrum certified mean that I automatically needed to reject and exorcise our team from this dangerous school of thought? I didn’t think so.

Don’t get me wrong – Scrum and other agile frameworks explain a thoughtfully evolved process for estimation that is rock-solid, clearly defined and often 100 percent part of the framework. However, not all agile frameworks are the same. Many teams use formal estimates with great success, and I want to be clear that I’m not advocating that there is one correct answer for every team.

The only thing I’ll advocate in this debate is to consider reasoning from all sides. To help facilitate this, I’ve prepared some points that are inspired by some respectful and intellectual discussions I’ve noticed on LinkedIn, various web development blogs and conversations with other professionals.

Below is a summary of some of the points that have stood out to me from the various discussions. Of course, this list does not contain every point that can possibly be made, so feel free to share your own points and express your own opinions in the comments section at the end of this post.

Points Supporting Less Emphasis on Estimates
For some teams, estimates are often inaccurate. While teams attempting to adopt Scrum and other estimate-supported agile frameworks will probably want to refine and improve their estimation process before abandoning it, some experienced programmers have found that the teams they work on over the years tend to have inaccurate estimates. They point out that these estimates often err on the side of over-optimism.
Some people intentionally provide inaccurate estimates. Some people believe in overcompensating, for example doubling their initial estimate to create a timeframe that’s twice as long. While this might ensure that fewer estimates are overly optimistic and fewer deadlines are missed, this can be problematic if the goal is to coordinate with other teams like marketing and sales, who might be caught off-guard by an earlier-than-expected release.
In many cases, accurate estimates are too difficult to provide. For example, if you’re being tasked with building an integration with a system or API you have little experience with, it could be challenging to form an accurate estimate. A lot of research would be needed, and necessary documentation could be inaccurate or lacking. There could be other factors, like the quality of libraries or wrappers provided for various programming languages, API stability, ongoing support and security, which could also affect an estimate’s accuracy.
Estimates are often misused. Rather than viewing estimates as a basic guess, teams can be tempted to treat them as hard deadlines complete with budgets assigned and people held accountable. Similarly, stakeholders often express disappointment when finished work isn’t delivered per the original estimate. In the very worst cases, teams are punished for needing more time than originally estimated, which can lead to a demotivated team, less accurate work and even less accurate estimates.
Estimates don’t make work ship faster. Any given work takes a set amount of time to complete, regardless of the estimate applied to it. The process of estimation, justifying estimates, explaining why actual work time varied from estimates and all other estimation-related activities can serve to slow down the team’s ability to ship work and deliver value.
Some teams become too focused on estimates rather than prioritization, scalability, careful scoping or other factors. Some teams divert so much attention to delivering per the estimate that they make sacrifices in other areas, like scoping the work carefully or making sure the work is scalable. This is harmful for the product and potentially delivers less value long-term. Points Supporting More Emphasis on Estimates Estimates can be made accurately, and there are ways to increase accuracy. The more you estimate, the better your estimates should become. Eventually, you can compare upcoming work to a larger historical data set of previous work performed by the same or similarly skilled and experienced team members. The more historical data you have, the more accurate your estimates will be.
Other teams need to plan business decisions around estimates. Marketing teams need to know when to launch marketing initiatives around major launches or updates, and sales teams and customer success teams need to know which features will be available, and customer support teams need to be staffed properly for a large release. No team wants to feel like they’ve wasted time and efforts by preparing for the wrong date, and they also don’t want to miss major opportunities by arriving late to the party.
Estimation can help set more realistic expectations. Some other team members or managers might take it upon themselves to assume how long work should take. Wouldn’t you rather set the expectations with your own estimation rather than open the door to other estimations from people who haven’t studied or scoped the work as carefully?
Estimates do not mean your workflow cannot be continuous. If you finish early in the sprint, you can pick up future sprint or backlog items that fit into the remaining time. How do you know they fit into the remaining time? They’ve already been estimated! In this way, estimates do not need to reduce work efficiency.
You need at least some kind of estimate to do an effective cost-benefit analysis. How can you know if it’s even worth doing the work if it could potentially take so much time and money that the costs outweigh the value delivered? How do you know this work is more valuable to pursue than other work, if you don’t estimate how much effort each is required to complete? Imagine agreeing to have a plumber fix a dribbling sprinkler head with no estimate and then learning the cost will amount to your entire life savings.
Estimation can reveal inaccurate expectations with burndown charts and other tools. Burndown charts can help show if work is proceeding at expected paces or if it looks like scope, time or budget will need to be adjusted to ensure success. This can be done without punishment for inaccurate estimates, but simply by responsibly tracking progress and comparing to customer expectations. Identifying any significant discrepancies early on can help moderate and readjust expectations to avoid unpleasant surprises.

Again, this list is not exhaustive, and not all points will apply to all teams. Some of these concepts may seem like they’re taken to the extreme, but I’ve personally seen, heard and read these exact concepts from real teams and professionals. Please share your own opinions and experiences in the comments section below, and let me know what you think about the value of #NoEstimates.

Agile Tips for Working with Non-Agile Teams

During agile training, we’re taught that everyone in our team should operate within the agreed upon agile framework. However, the question remains: how should we operate when interacting with less predictable teams outside of our own?

Once we get into the agile groove, it’s easy to feel complacent. After all, we’re pushing along at a productive pace and delivering shippable features iteration after iteration. Having all our team members working together with the same principles, methods and frameworks is very comforting – so comforting, in fact, that we might be afraid to operate in any other way.

On the other hand, the world beyond our nice little agile haven is a terrifying, stagnant realm filled with waterfalls leading nowhere and rigid, outdated plans that bend the laws of time. It’s easy to fear interaction with the scary, non-agile world, and it’s also easy to get frustrated when our colleagues or customers don’t have the same liberating habits that we do.

However, for many of us it’s impossible to avoid working with non-agile teams completely – and, as a matter of principle, we shouldn’t refuse to work with others before giving them a fair shot. I’d be willing to bet that almost all of us have, at some point, been required to collaborate with an internal or external party that has little to no agile training, let alone any kind of certification.

While you may be unlikely to suddenly convert the other side to an agile framework overnight, there is still hope. To help you smooth the edges of these sometimes-difficult interactions, here are a few simple, agile tips for working with non-agile teams.

Try Simple Prioritization

If I had to prioritize my advice, I’d prioritize prioritization. The internet is filled with prioritization templates and agile prioritization templates, but you might want to start with something simpler.

If you’re working with an external customer, chances are you can’t afford to exclusively accept agile customers while telling the rest to find someone else to throw their money at. Similarly, if you’re working with a non-agile party internally, you may be equally unable to control their level of agile training.

One of the most common problems faced by non-agile teams is unmitigated scope creep in the form of numerous concurrent requests with limited direction in regards to priority. In this environment, almost everything seems important, and by the way, why didn’t you finish this other important task over here?

Well, as we all know, the answer to that question is that we were busy finishing a more important task that had a higher priority. But, can we pinpoint how that priority was determined in the first place? If the customer isn’t prioritizing their own requests, then your team will be doing most of the decision-making independently (with some level of external input, of course). The more your team prioritizes on its own, the less customer collaboration takes place – and, as we already know, customer collaboration is an important value in agile.

When dealing with a non-agile customer or colleague who does a poor job of conveying the priority of a task relative to other concurrent requests, it’s usually easy to quickly summarize a bulleted list of the current requests and ask the customer or colleague to rearrange them in order of priority. Without realizing it, they’ll start forming their own prioritized product backlog.

Want to take it a step further? Try using one of the many agile prioritization matrix templates available on the internet. I personally like to keep things as simple as possible, but for a larger project and a larger scale of requests, having additional structure may be helpful to some teams.

Emphasize Progress in Iterations

Some people get spooked when you show them early iterations designed to tackle shippable increments. For many non-agile folks, their instinctual reaction may be something along the lines of, “where’s the rest of it?” or “yes, but we still need x, y and z…” and so on.

In these situations, it’s important to explain the advantages of delivering through iterations. Remember, these colleagues or customers may have never used iterative approaches in their careers, so what seems obvious to us may be an uncomfortable shock for the uninitiated.

The advantages of iterative approaches are numerous, but here are some highlights which might help you to convince non-agile colleagues or customers of its practicality:

Frequent demonstration of features and progress Frequent feedback and communication, which improves subsequent iterations Less likely to deviate from desired outcome Product can adapt to change quickly A cross-functional team can quickly shift resources as needed

You might not be able to get the non-agile party to obey a Scrum Master without question, but explaining the value of iterative and incremental development can plant the seeds of agile and ultimately pay off in the long run.

Suggest User Stories Before Solutions

Another pitfall for many non-agile colleagues and customers is the tendency to jump to a lengthy, prescribed solution without clearly and thoroughly explaining either the actual user need or the problem that needs to be solved. Rather than putting forth well-defined user stories that lead to constructive collaboration, this approach can often lead to the dreaded iterative waterfall that isn’t agile at all.

However, before you can expect a non-agile collaborator to write well-conceived user stories, you’ll first need to explain what user stories are and what their value is to the customer. Since the agile team needs to know what problem their work should be solving before they can build an effective solution, it’s in the customer’s best interest to write user stories that answer the “why” as extensively as possible before getting into too much of the “how.” Starting to develop the solution without clearly understanding the problem at hand is rarely a good idea in any setting, and the same holds true for your colleague or customer’s planning process.

Notice a Pattern?

When it comes to working with non-agile collaborators, the best way to ensure buy-in is to explain the value of agile processes. After all, why should someone be expected to adopt your methods if they haven’t yet seen how those methods can benefit them?

Prioritization, delivering over iterations and writing well-crafted user stories are just a few of the ways you can make your collaborative process more comfortable and effective when working with non-agile folks.

What are some of the challenges and solutions you and your team have noticed while collaborating with non-agile parties? What worked, and what didn’t work? Share your story in the comments section below.



3 Reasons You Need to Seek Feedback in Your Agile Process


When it comes to agile teams, far too many of us get trapped in the habit of working independently without a high level of external interaction ‒ this is especially true for teams working on software or web development projects.

While it’s understandable that working with others outside of your immediate sphere can initially seem stressful and overwhelming, investing a little time in clarifying details can go a long way towards cutting the number of iterations in your feature development cycle.

After all, the Manifesto for Agile Software Development teaches us that individuals and interactions, as well as customer collaboration, are core values, which should typically be prioritized over processes, tools and contract negotiations.

Additionally, agile methodologies like Extreme Programming make it a point to collect feedback from the customer on a frequent, ongoing basis ‒ but how many teams actually take that feedback to heart?

I’ve seen too many teams erroneously believe that a two-week sprint means blocking out all feedback from the customer, which can prove to be a mistake in the long-run. If you'd like to help your team move faster and collect as much information from the customer as possible, take a look at these three important reasons why your team needs to seek out feedback during your agile process.

1. You Need to Understand How the Customer Interacts with the Features You’re Building

Many agile teams understand that it’s important to collect customer feedback after an iteration is complete, but it can also be useful to collect feedback while you're in the process of building your shippable iteration.

Giving the customer a preview mode or prototype to interact with can teach you a lot about how they plan to use the features you’re building. Sometimes the way the customer interacts with the features you build is markedly different from the way in which they were expected to.

Using an abstract hypothetical, a car customer could ask an agile team to build an ejection seat to prevent death during a car crash, but their core need is more likely to be an airbag. Why? Because an airbag can better address their core requirement ‒ reducing death and injury with an efficient, cost-effective product that can get to market quickly.

While many agile teams understand the importance of collecting true customer requirements based on true user needs, why not do this on a much smaller scale as well? Your customer won’t wait for your two-week sprint to conclude before changing their mind or providing clearer requirements, so why not collect their feedback on a day-to-day basis?

Some folks may argue that all requirements should be collected perfectly up front, but making this assumption would be failing to prepare for the cases where requirements change or become clearer over time ‒ something that happens far more often than many of us want to admit. After all, responding to change is what agile teams are all about, so why block out input instead of seeking it as quickly and regularly as possible?

Sure, we can organize tasks and goals into short-term sprints without adding additional tasks or requirements, but if your requirements aren’t correctly and clearly defined at the outset of your two weeks, you’ll find that not communicating with the stakeholder during the sprint will surely result in an increment that could have better met customer needs.

2. You Need to Understand the Context of the Features You’re Building and the Work You’re Doing

The features you ship don’t exist in a vacuum ‒ real customers are interacting with these features and the results they produce. It’s important to understand how the customer interacts with the features you build on as frequent a basis as possible.

Talk to customers, and talk to them often. Don’t talk to customers solely on an individual level, but collect data on an aggregate level as well. Think about the industry or market you’re serving and its particular requirements.

In some cases, your customers may not even understand their own requirements as clearly as you can. For example, high school students might be the target market for a website or application designed to help them get into better universities, but these customers ‒ high school students ‒ may not even clearly understand the best methods to get into the best universities in the first place.

In other words, you may need to conduct research beyond customer feedback and in turn educate your customers about what they need.

There’s so much context that can help you understand the customer, which goes beyond their feedback ‒ terminology, regulations and laws, best practices and much more. Don’t assume your customers will simply tell you everything you need to know up front ‒ the features you’re working on may need to guide them or provide solutions that they themselves have not yet conceived of. 

3. You Need to Uncover True Requirements Much More Quickly

As I've already alluded to, it’s crucial to reduce the cycle of understanding requirements as much as possible. Idealists will tell you that requirements should be completely understood from the get-go, but this is often an unrealistic goal.

The reality is that requirements change ‒ the customer themselves may realize new requirements, laws and regulations may change, terminology may change and a slew of other changes may occur, all of which can lead to the introduction of different requirements. Ignoring these changes in requirements simply means extending the amount of time spent building towards incorrect requirements, which will ultimately amount to wasted effort on your team's part.

As agile teams, most of us like the concept of a protected sprint, but this shouldn’t blind us to the introduction of real changes in the marketplace or customer needs. The worst thing you can do as an agile team is ignore changing realities and, in doing so, fail to adapt to changing requirements.

What You Can Do About It

Want some actionable ways you can better adapt to changing conditions? Keep in constant contact with your customers and end users.

Do frequent research on the context surrounding your product and users, such as laws and regulations, marketplaces, terminology and any other relevant factors. Shorten feedback loops as much as possible ‒ do not shy away from customers, and force yourself to interact with them and ask as many questions as you can.

Remember, agile is all about responding to change, so staying ignorant to the changes surrounding your work is a fatal mistake. Don’t just respond to change ‒ seek to study and anticipate changes as quickly as you can, and you’ll be able to ensure the iteration you’re working on is heading in the most accurate direction possible.




10 Common Reasons to De-Prioritize Requests & How to Explain Them


Every agile team is faced with decisions about which requests or user stories to prioritize, and the choice can often be difficult‒especially when we’re expected to adapt to rapidly changing requirements.

When working with stakeholders or external team members, the process can be even more stressful as requests build up; stakeholders with competing interests may express disapproval if their requests are not prioritized over others or not completed in the timeframe they desire.

In these situations, it’s essential for an agile team to be able to de-prioritize or defer work to a later date, because time and resources are finite while requests can be infinite.

Many stakeholders will regularly check in on the progress of their requests and become frustrated if progress is not made as quickly as they prefer, however, in many cases, there are rational reasons for allowing new requests and work to supersede existing requests.

At some point‒or perhaps even frequently‒your team will need to explain why a request was deferred or de-prioritized, which can become an uncomfortable situation. To help you best prepare for this discussion and explain your decision, here are 10 common reasons why your team may need to de-prioritize a request and some examples of how you can explain your decision.

1. Newer, More Valuable Requests Have Been Introduced to the Team

Possibly the most frequent reason a task has been deferred is that more valuable requests have come up, which represent more value than older requests. Because agile teams are expected to adapt to changing priorities, and we can’t complete an infinite amount of work in a finite amount of time, something needs to be pushed a little further down the priority list or roadmap.

To help explain this, start with why the new request is very valuable and important to your users and organization. While it’s also important to explain why the older request is not comparatively as valuable, you may want to avoid beginning the conversation with reasons the request was devalued relative to new requests, and focus on the new opportunity being presented.

If the stakeholders care about the users and what’s best for your organization, they should understand why it’s important to complete newer requests that provide more value to the users you’re ultimately building the product for.

2. The Request Is No Longer as Valuable to the User

Sometimes the requested work will no longer deliver as much value because conditions change. For example, if a stakeholder requested your team build features that help users sort their recyclables into aluminum, plastic and paper, but the government no longer requires sorting of recyclables into categories, the request becomes far less valuable and possibly not valuable at all.

When explaining this scenario to your team, start with explaining the original value proposition (i.e., sorting recyclables), explain what condition changed (i.e., government regulation changed), and then explain how that change reduces the original value proposition (i.e., the change in government regulation reduced the need to sort recyclables).

3. The Request Is No Longer as Valuable to as Much of Your User Base

Let’s say you’re working on a product focused on college students at a select set of universities, much like Facebook did when it started. You may get requests specific to college students, such as advanced features for managing tuition, securing financial assistance for college and educational curriculum management.

However, your product may evolve the way Facebook did, to serve the entire world’s population above a minimum age such as 13 years old. Suddenly, requested features like securing financial assistance for college are only delivering value to a smaller percentage of your users, whereas previously, they benefitted all of your users.

Again, when explaining your decision to de-prioritize the request, explain the original value proposition and what changed to reduce that value proposition, but this time end by explaining how the change decreased the percentage of users who would receive value from completing the request.

4. The Request Deviates from the Updated Roadmap and Product Goals

Pretty much every roadmap needs to be adapted and modified at some point as product goals shift, and when this happens, there will be requests which are no longer as relevant.

For example, in the social network example above, it’s usually a conscious product strategy to shift from focusing solely on a niche market like college students and target a wider audience like the entire global population. During this transition, your current user base may still be college students, but you’re attempting to capture new markets with new user bases.

In this case, your explanation should start with what the original value proposition was, then explain the shift in your roadmap, then explain how the original value proposition no longer delivers the same value to your target market‒even if they’re not your current users yet.

For example, “The student loan management feature was very valuable when we were focusing on just college students, but our organization has decided to change our target market to include the entire global population; therefore the student loan management feature will only provide value to a small set of our target, expanded user base.”

5. The Request was Satisfied Another Way

It’s not unusual for a request to be satisfied another way, which makes the original request irrelevant or unnecessary. For example, a stakeholder may have asked you to build an electric scooter, but your team first built an electric bicycle that delivered more value to more users.

Once the electric bicycle was released, users who originally asked for the scooter ended up trying it out, and found that it met most of their transportation and enjoyment needs. Since most people were satisfied with the electric bicycle, they no longer saw urgently needed value in having an electric scooter.

In this scenario, explain the value proposition of the incomplete request, explain the value of the request that was completed, and then explain how the completed request provided the same or similar value to the user and how it decreased the user need for the incomplete request.

6. Completing the Request Presents More Risk Than it Previously Did

As your product changes, introducing new features or bug fixes can become more and more risky, as features and code start depending on other areas of the product.

For example, let’s say you’re building a publishing website that starts out with just basic blog posts. As your product matures, you develop more features that rely on blog posts‒feeds, categories, comments, tags, social sharing, canonical URLs, preview snippets, advertising and more.

When you were first building the product, someone requested private members-only restrictions on some content. Back when the only feature on the site was blog posts, this seemed pretty straightforward, but now that you’ve got a bunch of features relying on this core feature, things get a little more risky in terms of what can go wrong.

For example, could secure content introduce problems with SEO meta data, preview snippets, feeds and comments? Could disruptions in feeds be seen as a bug? Could email notifications about comments that are no longer accessible to non-premium members be seen as a bug? What about actual bugs?

For this scenario, the value to the user didn’t change so much as the risk presented by implementation. First explain the relatively lower risk of the request in the past, then explain the conditions that resulted in elevating the risk of implementing the request.

7. The Request Would Now be More Difficult to Support Than Previously

Similar to the above example of elevated risk, sometimes the resources needed to support the implementation of a request become elevated over time. A lot of the time, this is due to scale and complexity of the product, as well as user behavior.

For example, unlimited frequency of Excel exports for huge tables of data would be much easier to support if your user base was small and not expected to grow, but if you added a large number of users over time, you may want to put some restrictions on how frequently users can pull data and how large the sets of data can be to avoid crashes that harm all users.

In this scenario, explain the original resources needed to support the request at the time it was submitted, then explain what changed (i.e., user base size) which escalated the difficulty to support the request in the current state of the product.

8. The Request Could Be Better Handled by Other Resources That Weren’t Available Previously

Sometimes the resources available external to your team change and can better handle requests that were originally submitted to your team.

For example, maybe you were the founding team of developers at your company, which has since expanded to include teams focusing on specific sets of features or markets.

Your team no longer should handle all requests, and it’s very likely another team or resource will be more focused and do a better job on the request. Maybe the team of developers handling ecommerce features would be better suited for building out a new shopping cart feature.

In this scenario, explain the new resources that now exist and why they’re better suited for handling the request. Sometimes it’s developers, but sometimes it could be another resource like more manual workers or skilled workers who can perform data manipulation and custom reports in Excel, for example.

9. It Turns Out the Request Was Far More Difficult Than Originally Estimated

Similar to other examples above, sometimes changes in the product or other external factors make a request more difficult or costly than originally estimated. Going back to the content publishing website example, adding more and more features can make it more difficult to implement additional global features that interact with that newly expanded set of features.

In this case, explain the difficulty of the request when it was originally made, then explain what changed and how that increased the difficulty of implementation.

10. The Request Would Be Less Frequently Used Than in the Past

Whether it’s a change in your user base size or a change in user behavior, sometimes requested features just won’t be as frequently used as originally anticipated. A common scenario that comes up frequently is around bugs and bug fixes.

For example, you may be working with a video player technology that doesn’t support a specific browser as well as another video player, and a stakeholder may request that you change video player technology to better support all browsers because users are seeing too many errors.

However, your user base may shift their behavior and start only using the more widely supported browser, making the frequency of the video player error much lower.

In this scenario, you can explain the original frequency of the problem or need, and then explain what factor changed and led to a decline in the frequency of the problem or need for users.

It’s Not Always Fun, but It’s Why We’re Good at What We Do

Telling a stakeholder that their request is no longer as high of a priority as it previously was will rarely make them happy, and they may actually have negative feelings about this news.

However, shifting priorities is a key aspect of every agile team, and ultimately a main driver of what makes us effective and successful.

Hopefully the examples and scenarios in this blog post can help you better prepare for some of those more difficult conversations. Happy de-prioritizing!

What do you think? Let me know in the comments below.

Beyond Sprints: How XP Can Work for Modern Teams

Search “agile scrum” in the books section of Amazon, and you’re likely to find around 835 results. Search “agile extreme programming” and you’ll get just around 120 results back.

While this exercise might not be a scientific measure, it does reflect the dominant mindshare of agile discourse that Scrum has grown to achieve over the years. Indeed, just one look at the website of Scrum Alliance, and you’ll find six certifications specifically for Scrum, hundreds of Scrum training courses held around the world, corporate sponsorships, and essentially an entire commercial ecosystem ‒ none of which exist for Extreme Programming.

I have nothing against Scrum ‒ I went through Certified Scrum Product Owner training and found it immensely helpful. However, I don’t think Scrum should be where the discussion ends and I think other methodologies are far too often overlooked in agile discussions.

In fact, I’ve found that many of my well-meaning colleagues often start describing agile with terms like “sprints,” “estimates,” and “backlog grooming” ‒ but in reality, they’re usually describing Scrum rather than agile.

While Extreme Programming (XP) might not be for every team, I believe that every team should at least know what it is. Indeed, respected Scrum trainer and Scrum Alliance founding member Mike Cohn even wrote, “My typical advice to teams is ‘start with Scrum and then invent your own version of XP.’”

What is Extreme Programming?

Like all forms of agile, Extreme Programming emphasizes frequent releases and short development cycles to adapt to changing requirements and improve productivity. However, XP does not prescribe strict sprints, estimates, nor Scrum Masters.

In true agile fashion, XP posits that changes are natural, unavoidable and even desired when developing a software product.

Unlike Scrum, XP extends agile by emphasizing four key programming activities.

The first of these engineering practices emphasized is coding. Emphasis of coding is a stipulation that code is the most important aspect of software, and without it, no product would exist.

Coding is also seen as a fundamental tool in many working functions, such as using coding to find optimal solutions, and explaining concepts and solutions to others.

Unit tests and acceptance tests (testing), listening to customer needs and seeking frequent customer feedback (listening), and designing logic into the system to prevent an overabundance of dependencies and logic issues (designing) round out the other three programming activities that XP emphasizes.

Similar to Scrum, XP also has its own set of values: communication, simplicity, feedback, courage and respect. These values all reflect core values of the Agile Manifesto, emphasizing the people and interactions needed to get working software built, as well as maintaining constant customer collaboration and responding to change.

What Are the Advantages of Extreme Programming?

In my own personal opinion, I find XP to be less prescriptive in practice than Scrum. I think far too many professionals latch onto a framework like Scrum and begin mandating it in the most rigid way possible, which runs the risk of being contrary to the Agile Manifesto by overemphasizing processes, tools and plans.

While many teams stand to benefit from the more elaborate framework and processes offered by Scrum, more nimble and self-disciplined teams are able to thrive with less procedural overhead.

Indeed, many teams are even reminding us that processes like estimates are not necessarily a must-have, and may even be counterproductive at times. Many people are shocked when I remind them that estimates aren’t actually a universal aspect of agile, nor specifically prescribed in popular methodologies like Kanban or Lean.

In addition to being liberating and removing processes which can slow teams down, I believe that XP is more adaptive to change than Scrum, as it usually allows changes within planned iterations.

I’ve seen far too many Scrum teams get locked into the idea of following two-week cycles as a default, whereas XP seems more compatible with modern practices like shipping code and features multiple times a day.

This isn’t to say that XP is all about throwing all process to the wayside. On the contrary, I believe the emphasis on practical engineering activities like testing and pair programming helps keep teams focused on processes that have a much clearer impact on actual work quality, rather than business planning measures like estimates and sprint velocity, which tend to feel more indirect and distracting from getting the actual work done.

Finally, I personally like the fact that XP emphasizes frequent communication with the customer. By frequently talking to the customer, the team building the software can uncover misunderstandings or changes in requirements and address them more rapidly, rather than adopting the mindset that they’ll wait to present their work to the customer at the end of a sprint.

Can Extreme Programming Really Work?

Extreme Programming isn’t for every team, but it could be. With Continuous Delivery and streamlining of deployment becoming more and more common, I believe that Extreme Programming is a very appealing methodology that emphasizes meeting customer requirements and facilitating development without processes that hinder work.

In my own experience, I found Scrum to be a great introductory framework full of interesting ideas, but over time, I found that the practices and values of XP were more in line with what our team actually needed to function closer to our peak performance capabilities.

In fact, my team never set out to adopt XP and we never talk about it ‒ it just so happens that most of what we decided works well overlaps with XP practices, values and principles.

With this experience in mind, I wasn’t surprised at all to read Mike Cohn write, “The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them themselves rather than having them mandated.”

Take a look at your own team practices and discussions about what works and what feels like a detractor from effective work. You may be surprised to find yourself closer to the XP side of the spectrum than you may have realized!

What’s your take? Let me know in the comments below.

3 Agile-Friendly Ways to Say No to Feature Requests

I recently interviewed a product manager from a well-established company. I was curious about how they handled feature requests and asked if there were ever times when the PO needed to say no to feature requests. I was floored with his reply: “No,” he said. “I prefer not to work at a company where we say no to requests.”

Sounds nice, right? Unfortunately, good product management means saying no frequently, and every agile team should know that regularly rejecting feature requests is an important part to creating a sustainable, effective product.

After all, one of the 12 principles of agile software says, “Simplicity--the art of maximizing the amount of work not done--is essential.”

To illustrate why saying no is actually a crucial aspect of agile best practices and to provide helpful ways to rationalize rejection, here are three common examples of when a good agile practitioner should reject a feature request.

Scenario 1: The Feature Request Serves Only the Loud Few

Your restaurant customers in Maine are asking for a system-wide alert any time there’s a lobster shortage. Everyone needs to know when it’s time to start hoarding lobster, right?

Well, if your product is serving the entire United States, most regions don’t have a lobster-heavy restaurant industry, and Maine only represents 0.42 percent of the country’s population. You might instead want to build a feature that serves both Maine and the rest of your customer base.

Ways to address:

Check with a larger sample size of customers Check the value of the customers—are they customers you can’t afford to lose? Or users who signed up for a free trial and aren’t paying? Check to see if the change could negatively impact customers who didn’t request it Opportunity cost: Bust out the microeconomic theory. Are there other features in your backlog that could deliver more value to more customers?

The agile angle:

Simplicity is essential Deliver more value with features that benefit more users, or more valuable users Scenario 2: The Feature Request Does Not Scale

A feature request comes in that requires you to set up a new public API with a huge volume of constant API requests. Your servers can handle it for the first few pilot customers, but if you try to roll it out to all of your current customers, your API service will be overloaded with requests. Your colleague asks you to add more server resources and a dedicated team to support the API, but customers aren’t paying anything additional for this service. The feature request does not scale, and if no one is willing to pay for the feature, chances are it’s not adding enough value.

Ways to address:

Ask your team to envision or simulate rolling the feature out on a larger scale. If it succeeds, can you afford to sustain it? Ask for proof of concept that shows the customer truly values the feature, i.e., they’re willing to pay for it or it’s needed to reduce customer attrition

The agile angle:

Agile processes promote sustainable development Scenario 3: The Feature Request is in the Contract, So it Must be Done

Your client asked for a feature and is ready to pay you to build it, so you should definitely build it, right? Actually, the customer might not know that there’s a better solution that could save them time and cost, while also delivering additional value.

As the agile practitioner, it’s your responsibility to collaborate with the customer to inform them if you believe a feature will not deliver value to them or if there’s a faster, more valuable, or more sustainable way to satisfy their user story.

Ways to address:

Take a few minutes to see if there’s an obvious solution that’s stronger Don’t stay silent, inform the customer of potentially better solutions and explain how it would deliver more value to them in a shorter period of time If necessary, explain to them why adapting to a better solution is usually better than sticking to a weaker original plan

The agile angle:

Customer collaboration over contract negotiation is one of the four values of the Agile Manifesto Responding to change over following a plan is another core value of agile An agile-friendly customer should value collaboration and responding to change, especially if they’re internal to your team or company Delivering more value on a shorter time scale is consistent with agile principles Conclusion

Regularly reflecting on how to become more effective as a team is yet another agile principle we should all adhere to.

Think about your own pursuit of being an efficiently functioning agile team. Do you find yourself saying no to feature requests periodically? What are some of the most common cases for you, and how do you address them in a way that’s consistent with agile best practices?

Let me know in the comments below.