Planning for excellence

Moving from reactive to integrated planning makes things better for everyone involved

Planning is integral to every successful design project. Knowing what work the Design team needs to accomplish and the timing of that work can help us achieve excellence. Depending on the maturity of the offering team, you may be in one of the following planning stages:

• Reactive planning: Reacting to a ton of development requests for design support
• Siloed planning: Planning your design work based on the release objectives
• Integrated planning: Planning your work with the development team

Reactive planning

The reactive planning world is where most Design teams tend to live. One day the Design ask is to deliver 300 icons for the toolbars by Friday (and it’s Thursday afternoon). The next day, Development wants feedback from customers because the director asked for customer quotes. Most of the time, they don’t even know what they are requesting or how long it will take. The release cycle began with only Development doing the planning for their effort, typically ignoring anything that isn’t coding.

This lack of planning causes Design to be in a reactive mode, responding to roadblocks that Development runs into while coding. Management and offering managers (OMs) typically are not happy with the results, so their reaction is to ask the Design team to “fix it.” This approach doesn’t allow Design to plan their work or discover fundamental usability issues that prevent the user from reaching their goals. Not having a plan prevents the Design team from creating a proper interface design that is validated by research with actual users.

Unfortunately, many design teams get stuck in this stage because a few stakeholders are driving the offering team through a to-do list. The offering team lacks an overall strategy or vision that would lead to better planning. To get unstuck, designers should start to leverage their connections with developers and OMs to get ahead of what’s coming up next. Knowing what’s coming allows the Design team to begin planning their work and to make changes proactively throughout the process.

Siloed planning

Getting ahead of the work by obtaining the release goals leads to the second stage of planning. The Design team breaks down tasks in an ideation session. The team looks at the dependencies of the work and gives a relative size to each item to understand how long it will take to complete. We place work items on a physical or virtual Kanban board so everyone on the Design team (but probably not developers or OMs) can see the work and overall status, which gets reported back to management. The team goes into execute mode, accomplishing tasks and handing outcomes to Development.

As the team gets comfortable with these methods, they will start to adopt the sprint concept to validate the work every few weeks in order to make any adjustments to tasks and possibility sizing. While work is getting done, because everyone on the design team has a task to complete, there are drawbacks to this approach:

• Plans tend to be optimistic, causing mad scrambles to catch up at various times during the release cycle.
• A lack of transparency since only the Design team can see their plan and status, which leads to more meetings and charts requests.
• You end up attending daily and weekly status meetings to share outcomes and status with various stakeholders since most are working independently on their own sprint goals.
• There is no “single source of truth” to understand the project overall since plans reside in multiple locations.
• You are missing out on critical changes in direction and roadblocks that can happen during the release cycle.
• Overall, team capacity is missing since Development, Offering Management, and Design are tracking their work independently, typically over-committing on the work required to complete the project.
• Shared activities like workshops, user research studies, design reviews, and technology impact are missing from these plans, which makes it hard for everyone to collaborate on these activities.

While there is a plan that might seem reasonable to complete in a sprint, the above drawbacks start to add up over time. As I’ve watched Design teams over the years, the best case I’ve seen is where one day of the two-week sprint ends up being dedicated to planning activities addressing most of the drawbacks of this stage. The Design team is happier overall, knowing what’s expected of them by a deadline. Keeping the Kanban board updated typically leads to fewer meetings. However, the Design lead starts to spend more of their time doing project management activities instead of spending their time on designing the experience.

Integrated planning

To solve all these drawbacks, we need to plan and work together. To start, we need a common way to track work across all teams on the project. Development teams have spent years building and using various project management tools. These tools track work in epics, stories, and issues. Epics are typically the overall goal which provides some new value to the user. At IBM, the epic is a combination of the outcome (represented as a Hill) and the ideal scenario expressed in the To-Be. Epics contain a series of stories, which are a breakdown of the steps in the To-Be. Issues are problems found in the working code, broken down by severity.

Understand that this is a simplistic way of describing these concepts, and depending on the process adopted by a development team, the details in epics and stories can drastically vary. There are several tools on the market today, like GitHub and JIRA, that track work using epics and stories. Picking this tool should be a conversation with the offering manager and development leads; it doesn’t matter what tool you pick as long as the goal is to use a common tool for tracking work. There will be a learning curve no matter the tool, and the Development team will need to be open to working in this new way. Up to this point, most Design teams were often only allowed to open issues and possibly contribute via a review of the epics and stories. Planning together will be a culture change for the Development team, but it’s one that will benefit everyone. The Design team can use the above list of drawbacks to start the conversation to convince the Development and offering management leads of the benefits.

Once we’re in the same tool, we all need to start planning together. Planning at the offering level gets a bit tricky the first time around since the conversation will appear to be foreign. It’s easy to be a fly on the wall and listen to Development break down work, assign a size, record the story, and move onto the next item. You mustn’t fall into that fly trap. Start by adding the work the Design team needs to accomplish as stories to achieve the goal in the epic. Remember to include tasks like workshops, conference presentations, demonstrations, marketing website updates, and anything else you think the design team might assist with during the development cycle. These are the team tasks that everyone ends up working the weekend to complete. Hopefully we can avoid that situation by including it in these planning steps. With a list of stories, we need to give an estimate of the amount of work to complete.

As a team, use planning poker to estimate the amount of work to complete the story. Don’t get too hung up on the number representing a time frame. You and the designer working on the project just want to agree on a number. After a few sprints, you’ll understand how to use the categories and how much work (capacity) the team can complete in a sprint. Watch the estimations. If everything has a large number of story points, you either need to break the story down further or do some research to break through the unknowns. You should end up with a good mixture of low-sized and medium-sized stories as well as a few large-sized stories.

Red Flags
When you see your team creating sub-epics or sub-stories or sub-anything, there is a problem with the way you’re planning. These sub-things break down huge goals which might take years to develop. While there is nothing wrong with long-term goals, planning should focus on short-term goals that deliver value to the end-users. Otherwise the team risks missing changes in the market and other opportunities. Push on the team to describe the value of these sub-things and convert them into a series of epics. Typically, the commitment will be to one of these new epics for a release cycle.
A different approach is to prioritize the tasks of the end-to-end experience and remove low-priority experiences. Rework the epic to focus on that minimal viable experience (MVE) and create a future epic to cover the next phase. That way, you’ll keep making incremental progress towards the long-term goal and can easily redirect if the market changes.

Some development teams will leverage multiple epics. For example, say you have three goals for the release. Each goal may become a different epic. Assign one or two designers to work through the breakdown for those epics. Having a delegate plan their own future work will make them more invested in the outcome and will grow their leadership skills. As the design lead, don’t insist on attending every planning meeting as that can tie up your time and make you a bottleneck. By reviewing the plan within the tool or in a quick follow-up meeting, you can spot check and make sure the delegates didn’t miss anything. You can also work on the sizing estimations together. With everything ending up in the tool, the offering team can collaborate on what goes into each sprint.

At the end of the planning cycle, you should have a handful of epics and 20+ stories per epic. Work out the dependencies between stories with the OM and Developers. Now you should see the real benefits from the new single source of truth:

• Everyone, including stakeholders, can see what stories are in the backlog, in progress, or completed improving overall transparency of the work.
• There is better alignment across the team regarding story priorities and changes in direction since outcomes of decision change epics and stories.
• Development metrics include Design’s effort so there is no need for separate reporting of status and tasks to complete.
• Overall, there’s a better representation of the entire team’s capacity, work completion rates, and early warnings when the project is going off track.
• Accountability is well understood since each story is assigned an owner and most tools allow for a discussion.
• More alert to the daily flow of work since you’ll be in the tool watching changes in real-time.
• The team can spend time on a single unified end-of-sprint demo, showcasing all the work that is complete.
• Identifies work that needs the entire offering team support, so we don’t end up working weekends to catch up.

These benefits are well worth the awkwardness of the first attempt at planning together. Like most changes, it will take a few iterations and adjustments to make it work well for everyone. As you make modifications, search the internet for different techniques or adjustments that other teams have made. Over my 20+ years working with teams in software development, I’ve seen hundreds of techniques come and go. What’s important is that you’re planning together and recording the plan in a single source of truth. There is no right or wrong way to plan (well… maybe this whole sub-trend…) as long it makes sense to everyone involved and you’re meeting the above goals.

In your pursuit of planning for excellence, the ultimate question to answer is: “Are the outcomes we are building going to deliver value to our user?” Once you’ve done the hard work of planning, you have a much better answer to that question. Good luck, you’ve got this.

BJ Scheid is a IBM Distinguished Designer at IBM based in San Jose, CA. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.