How we refine your software solutions’ needs, wants and expectations into a usable roadmap in just one day.
Our Feature Workshop is an interactive collaborative brainstorming session facilitated by a certified scrum master. In our world, it is the cornerstone exercise for refining the needs, wants, and expectations of our client’s vision into a usable road map.
The goal of the Feature Workshop is to form clarity from chaos, direction from misunderstanding, and identify the minimal time to business value.
4 Phases of the Feature Workshop:
Dreamboard
The first step of our process is homework (sorry!). This is where we gather the high level information about the solution, such as:
- Product Name
- Goals
- Target Users
- And other factors that determine if the product is a success or failure
All of these questions will help us better understand the problem you are trying to solve and help us determine the right kind of questions to ask during the workshop.
Brainstorming
Brainstorming is the meat of the Feature Workshop day. The goal of this section is to challenge participants preconceived ideas about the solution, while recording any and all new ideas that are generated. Its our job to collaborate with our clients and ask the questions that make them say “Huh, I hadn’t thought of that”. While the point of this section may not be to perfectly define the scope of work to come, we believe that somewhere, buried in the piles of resulting sticky notes, are the gems that will solve our client’s problem
Now, Next, Later
One of the foundations of Agile development is the concept of smallest possible feedback loops.
Gone are the days where projects are expected to stay shuttered and hidden, only being released upon 100% “completion”. Instead, the Agile community has embraced the fact that business problems change much faster than solutions can be completed.
What good is the ultimate business solution if three other competitors have launched, failed to interest customers, and pivoted to something new before it even gets in front of a user? Worse yet, not only does this place you behind the competition but now you’ve burned a large portion of your capital to get there, ouch.
This section of the process focuses on identifying the most important and least understood aspects of the solution and prioritizing them within a backlog of work items. Maybe your solution relies on unproven technology, or maybe the whole concept rides on the assumption that customers will use the solution in a specific way. We can make educated guesses about how these things will play out, but without validation it’s essentially a gamble, and one that companies lose every day.
By front-loading these types of problems, we’re able to minimize the amount of time (and money) that will take before a solution can start generating valuable feedback.
As the prioritization of work items begins to filter the riskiest assumptions to the front of the solution, another scrum concept begins to take shape. The Cone of Uncertainty is a term used to describe the decreasing variance in estimates as ideas are validated. It is almost a universal truth that early estimates are either naively low, or frustratingly high, and it’s this large gap that represents the base of the “cone”.
However, as stewards of our client’s vision, it’s our job to take this massive variation and narrow it as quickly as possible via early and frequent iteration over the aspects of the solution that cause this uncertainty. In doing so we’re able to drastically reduce the variation in estimates, provide more accurate projections, and reduce the chances of wasting resources.
Like most aspects of an Agile Methodology, the backlog produced in this section is intended to be reactive to an evolving understanding of the problem. As information is gathered, work that was previously considered critical may shift in priority or even be abandoned altogether. A well-maintained backlog will ensure that uncertainty is minimized and resources are used appropriately.
Relative Estimation
At this point in the process it’s time for homework on our end. We compile the results of your brainstorming, backlog creation, and prioritization, then gather our best and brightest minds to create our initial forecast of the solution in its entirety. Additionally, we’ll provide a separate, refined roadmap defining what we view as the minimum amount of functionality that can survive on its own, or Minimal Viable Product.
To do this, Sigao uses a proprietary relative estimation technique to produce our initial forecast of the solution. By assigning effort to new work items based on problems we’ve solved in the past, then estimating items in relation to each other, we’re able to create what we believe to be a realistic forecast for how long and how much it will take to provide a solution to your problem. While this often results in an estimate that is more uncertain than people are familiar with, we believe wholeheartedly that it’s better to be honest rather than make promises that can’t be kept.
We’re also proud to say that the vast majority of our solutions are completed near the center of our projections.
Roadmap
One of the most common misconceptions about an Agile process is the perceived lack of planning. For many, it seems inconceivable to begin work without piles of planning documents, generated by teams of business analysts, defining every feature and every milestone of the work to come. On the surface this seems like a logical conclusion. When time, money, and jobs are on the line, it’s a natural human response to seek comfort in knowing that there is a plan. People tend to focus on their successful predictions to trick themselves into thinking they’re capable of knowing the future, while conveniently forgetting about the number of times they were wrong.
Sigao’s response to this is simple: Name a single time you drove from one city to another where you were able to predict every turn you would make, every pothole you’d dodge, every traffic jam you’d encounter, and every animal that would run out in front of you along the way, before you even left your home. Now consider that a project will have multiple “drivers”, of multiple skill levels, all trying to do something infinitely more complex than drive a car. How comforted does an all-encompassing plan make you feel now? Ya, that’s kind of what we thought.
The answer is to visualize the solution at a higher level, acknowledge the uncertainty, and plan for it. Rather than trying to predict every fine detail, we use the prioritized work items to construct a forecasted timeline of high level feature completion (both for MVP and total solution backlog), with estimates becoming increasingly less accurate for work items farther in the future. The most valuable research will get done first because we’ve already front loaded the riskiest assumptions, which in turn will drop the uncertainty of future estimates.
This process is the reason that we reject the notion that an Agile Methodology does not involve planning. Our plans are just dynamic, and evolving, maintaining their relevance by being subjected to constant evaluation. We are always planning, from the Feature Workshop to the very last sprint. When we deliver the initial road map at the end of the workshop we’re providing an honest assessment of the information as it stands, with the expectation that it will adjust along with our clients’ needs and goals.
| That was a lot of information! Let’s recap: The Feature Workshop is a low risk, low effort way to define your solution. You’ll interact with industry experts that will advise on implementation. After, you will have a Forecast for your solution, identifying the minimal time to business value. |
