Welcome to the final stage of our planning journey. We have an idea of where we’re going in the form of a vision and a set of key objectives. We understand what the destination looks like due to our business and technical models. Now, we need to draw a roadmap that will form the step-by-step directions for the journey before we can start coding.
The end result is a detailed feature map and a five iteration plan that lays out exactly what we’re going to do over the next ten weeks. This is not your typical work breakdown structure, however. At Kingsmen, we do things a little differently.
Breaking it Down: The Difference Between the Kingsmen Way and a Work Breakdown Structure
After establishing a vision and a set of domain models, the final step in the planning process is to break work down into smaller and smaller chunks until you’re left with a single function that a software developer can build.
Typically, developers accomplish this using a work breakdown structure (WBS). A WBS is a list of project requirements, actions and tasks that must be completed to deliver the project successfully.
“A work breakdown structure is a deliberate method of breaking down project requirements into tangible, manageable nuggets,” explains Jasmine Lee, former senior market research analyst at business software reviews provider G2. “A well-oiled WBS is integral to the success of a project. With WBS, the project manager or team lead can drive efficiency, accountability and productivity. Instead of getting lost in the weeds or undertaking a project without proper oversight, a work breakdown structure divides and conquers.”
Our feature map and iteration plan look a little different. We break down the domain and technical models developed previously in the planning process into:
- a set of capabilities (the highest level abilities the product will have).
- features (those capabilities broken down one level further).
- functions (features broken down one level further still).
We also calculate the size of the work and the order in which each capability, feature and function need to be completed. This creates a map reading from left to right that shows exactly what needs to be done, how long that work will take and in what order it must be completed.
Unlike a WBS, we don’t break everything down to the task level. That’s one step too far, in our opinion. It’s common for businesses to prioritize some capabilities and eliminate others when they see everything laid out in a feature map. By stopping at functions and only planning work for five two-week iterations at a time, we make sure we don’t waste time planning features that won’t get built.
How We Approach Creating a Feature Map
As with every stage of our planning process, we first meet with subject matter experts within the business. When mapping out the more technical elements of the development, we rely on the knowledge and advice of in-house developers, analysts and key stakeholders to make sure we have all the information we need. Only then do we begin creating the map.
The domain models created previously form the foundation of the feature map. To recap, this maps out how entities in the business relate to each other and illustrates how work is completed. From that, we create a use case diagram that shows who will use the system and how they are going to use it. And from that we draw out the capabilities, features and functions that form the feature map.
As an example, let’s say we’re creating a grade book for a school. Users will include a teacher, an administrator, a student and parents, and so the use case diagram will need to show how each of these entities interacts with the product.
Our grade book program will need the ability to manage teachers and manage courses so teachers can be assigned to courses. Course management and teacher management would therefore become capabilities in our feature map.
Breaking down courses further, we’ll need the ability to manage the courses themselves and manage classes that constitute the course —these will be features. Going one step further, listing, creating, editing and removing classes will all be functions of class management. We do the same process for every product capability.
At this stage, it’s important to prioritize the development of the capabilities, features and functions. For example, we need to create classes before teachers so we can assign teachers to classes. We also estimate how much time each step of development will take. As you’ll have guessed, some of these capabilities, features and functions will be similar; there’s not a lot of difference between teacher management and student management, for example. Therefore we’ll allocate slightly less time to creating students if we’ve already created teachers.
Once everything has been considered, every capability broken down and every function assigned work points, we have a finished feature map that stakeholders can use to prioritize work. That’s one of the big benefits of this kind of approach, says Atheek Razick, a senior consultant at software development company TIQRI. “Building a holistic visualization of all the work that would be required to deliver a fully fledged product can help the project team decide on what is critical for a product to run smoothly, organize work into releases and de-prioritize work that has less user value.”
What Are the Strengths of the Kingsmen Way?
Visualizing work clearly is not the only benefit of our approach, however.
One of the main differences between our feature map and iteration plan and a WBS is the level of traceability. A feature map lets you trace everything back to a single capability while showing you how every capability, feature and function interacts with everything else. This makes it easy for stakeholders and developers to understand what needs priority and how delaying one capability or feature can impact the wider development.
Sizing is another strength of the Kingsmen Way. Because we have such in-depth modeling conversations and we understand our team’s velocity, we can accurately predict how long it takes to deliver both a specific feature and the entire project.
There’s no chance of missing work using our approach, either. This is arguably the toughest part of creating a work breakdown structure, but it’s what our models are built for. Everything has been accounted for and broken down so that stakeholders can pick and choose features depending on their priority.
Increasing this kind of visibility is what makes agile development so powerful, writes the team at Kissflow. “With increased visibility, predicting risks, and coming up with effective mitigation plans becomes easier.” This is carried through to development, too. “Scrum methodology, for example, uses sprint backlogs and burndown charts to increase the visibility of the project which allows managers to predict performances and plan accordingly.”
An Iterative Approach
The feature map is the final part of our customer success planning process and the last item to be checked off the list before we start development. But it doesn’t end there. Like objectives, key results and models, we constantly iterate our feature map throughout the development process.
It is a living document for us, and as such, is constantly reviewed and adjusted if new features or capabilities need to be accommodated. Priorities are constantly changing in enterprise developments, after all, which is one of the reasons we only plan five iterations at a time instead of the entire project at once.
Our five iteration plan allows organizations to change their minds without impacting development to any great degree. It also allows us to accommodate external teams who are dependent on our work or who we depend on ourselves. With a feature map in place and five iterations scheduled in advance, everyone can plan accordingly.
Images by: Tool., Inc, Kvalifik, Charles Deluvio