How to Ease Scope Creep in a Balanced Team
Our team has been using Trello as our product management tool of choice over the past year. I documented a detailed workflow a few months ago in another post.
As with any process, there were several issues that we never resolved:
How to manage scope creep?
How to document design stories?
How to prevent backchannel discussions?
How to manage a crazy, exhaustive and mostly redundant product backlog? How often do you actually really revisit those stories?
When Chris Butler started working at Philosophie as a Product Strategist, he suggested that we use what he called the “Inbox” method of managing new stories.
Inbox is not a backlog. It’s a rigorous way to document, discuss and prioritize all tasks we do on a project.
Here’s what we’ve done in the context of a week-long sprint:
Friday, a sprint’s end:
Review user research findings and stakeholder objectives. In the below example, here were some action items we identified over the previous 4 days:
Set a couple of themes for next week. We like to have an R&D theme (first bullet point) and an engineering theme (second bullet point). My coworker Aliya Marder has written an excellent post on how to collaboratively unpack and prioritize themes:
Branching off from these themes, user findings and objectives, propose new stories. Add them to Inbox.
Monday, a new sprint’s beginning:
Gather your whole team together for Sprint Planning. Discuss and decide which stories should be moved into “To Do” and which ones to Archive.
How do you know what’s worth moving? These are some general guidelines:
Is the story directly related to achieving success pertaining to the theme? Move it.
Does the story fix a broken experience? Move it.
Is it unrelated to the theme? Archive it.
In the above example, given the themes on the far left, the story in Inbox, while valuable when we ultimately ship the product, is out of scope for this week. So we archive it.
Is it an enhancement, or “nice to have” story? If your users haven’t expressed difficulty or concern in testing, Archive it.
Review all stories in “Inbox” until every story has been moved or archived. This is what we like to call Inbox 0.
During the sprint:
Idea for a new story? Put it in Inbox.
Caught a bug? Put it in Inbox.
While working on a story, you catch another task you can complete to enhance the story? Put it in Inbox.
Stakeholder tell you to fix something or complete a task for them in a private message? Put it in Inbox.
Need to watch User Testing videos and summarize findings?
Put it in Inbox™.
Every day, or preferably twice a day:
Bring everyone together for an Inbox review. This meeting shouldn’t take more than 15 minutes. As a group, decide whether each story should be moved or archived with the same process above. Be vigilant about keeping your Inbox “clean”.
This all seems a bit aggressive.
It might seem scary at first to be so aggro about archiving stories. What if we archive an a request a client feels strongly about? What if it’s something we need to build later?
This Inbox method is contingent upon a shared agreement that when we set a theme for the week, we (the product team, the product owner and the stakeholders) understand that we really stick to it.
And, if a story really is important, it will come up again as a topic of discussion.
