Rule #4 From the Manifesto for Agile Development
I asked my best friend, a talented lead software engineer at a mid-size company, “What’s the best part of your job?” He’s not the type of guy who’s prone to think about that stuff and he just mumbled something to make me go away. So I was surprised when I asked him, “What’s the least favorite part of your job?” and he quickly complained, “My product manager adds to our sprints after we’ve already set them…in the middle or even the end of them…and it happens every time!”
Further probing revealed that this is a common pattern that he feels helpless to break. Yet, when I asked him if this means longer hours he revealed that “no, it means lower quality.” They are an agile shop and move quickly, so the PM has been conditioned to respond quickly to change. For good measure — he is simply following Rule #4 from the Manifesto for Agile Software Development — Responding to change over following a plan.
In theory, using Agile development methodologies should keep the product team disciplined and happy, delivering value fast to real-world users. In reality, far too often one of the results of “Responding to change over following a plan” is that sprints are fattened up when changes in priority happen, leading to lower quality releases and frustrated development teams.
Responding to change over following a plan sounds great, doesn’t it? When I hired a contractor to build my deck, he didn’t have a problem responding to my change requests. He simply took longer to build it and charged me more. So why do product managers expect a development team to add more to a sprint while still meeting quality goals and key dates?
It’s not an easy job, being a product manager. Internal and external constituents are coming at you from all directions with needs and wants. Since every feature is competing with another, it’s important to have an objective measure of priority but in many cases, the measure of priority is driven by opinions, politics or top-down pressure. When this happens, it’s easy to fall into the trap of adding to a sprint without considering whether you really should and what the trade-offs are.
No one is saying it’s easy making trade-offs and watching something you previously deemed important get pushed to the next sprint, but it’s an essential part of balancing responding to change with mitigating risk. Taking back the power to prioritize by grounding yourself in the product vision and strategy will set you and your team free from needless frustration. It won’t change the need to change your product roadmap and add to sprints, sometimes pushing out a priority and other times filling the bucket of “what’s next,” but everyone will understand why.
The key idea is to root your “what’s in versus what’s out” process in your product strategy and to follow these three steps when you are thinking about adding to a sprint: #1 Have a documented strategy that’s understood by the product team (this assumes you have done this work upfront). #2 Ask “Does the new “must-add-to-sprint” feature tie to the strategy?” and #3 communicate how it’s tied to the strategy so the team understands why it’s being added to an already full sprint. Let me explain a bit more.
#1 Have a documented strategy that’s understood by the product team The company’s strategy is the “why” — meaning it’s answering why the market cares about the product you’re producing. Aligning strategy to each sprint and each story helps a team understand “why” and knowing the value of one’s contribution is critical to fulfillment and quality work.
#2 Does the feature tie to your strategy? Product Managers must protect their teams from subjective and politically motivated prioritization. The good news is that once a strategy is understood, it’s not difficult to come up with a scoring system everyone can agree on. When each feature’s score is based on the product strategy, saying “No” is much easier because it’s informed by objective metrics. Consider reading this related blog post on this subject: You aren’t saying “No”. The Strategy is.
#3 If the feature is strategic….remind the team why it is important to add It’s going to happen. You’re going to need to add features that will take the sprint over capacity. Life is not perfect and neither is Agile. However, if you do need to go this route you’ll have a happier team if you communicate why it’s important to the strategy. It goes without saying that you should try to make this the exception, not the rule.
At the end of the day, what’s important is having, using, and communicating a clear strategy that will take your company where it wants to go. This gives everyone the background info they need and possibly even a sense of ownership in the process. You may just find that the next time you make your case for increasing what’s included in a sprint, the team may not view it as “My PM added to the sprint” but rather “We had to add to the sprint.”
If you are not already an Aha! customer, you may want to sign up for a free 30-day trial of Aha! now to see why the best known software and web companies are using Aha! to set brilliant product strategy, create visual roadmaps, all while being loved by their team.
Tell us if your sprints suffer from feature creep bloat and give us a vote on Hacker News.
Follow Aha! @aha_io
