What options do we have to integrate a UX/UI team into our Scrum process?

Although this question doesn’t come up all the time, it certainly comes up enough that sharing how our team made the decision to keep the Design team work outside our scrum team’s sprint could be helpful to others.
Just to give you some background, this team has been focusing on the intake of new projects, how we define new projects and what information is needed to ensure we make good business decisions in the future.  And, since this post references some processes in a previous post, you may want further clarification, so check it out here.
Our team has had many organizational changes over the years so we decided to take time to evaluate our agile practice and our teams to see how they were doing.  During our reviews, we heard that our design team wanted to understand how they would participate in our scrum practice and previous attempts weren’t going well.  So, to keep our discussion simple and make a decision quickly, we had leads from Product, Design and Tech review two options that we could use to plan and execute with consideration for how design/UI/UX is integrated into the process we continue to evolve.  Take a look and come prepared with your input on which option you believe works the best for your team.
Each option assumes…
…for each new project that is approved and moves to the “COMMITTED” status, we will have release planning with all teams invited (product, design, tech, ops, etc.) before we begin so that everyone understands the goal of each release (if there is more than one per project) and what high level features are being requested.  
…at the end of the release planning session, each team comes up with their estimated schedule to complete the project and each release/milestone along the way. This is the way we create the CPE (Concept Phase Estimate) and projected completion date and the project moves to the “READY” status in our Intake workflow.
Red text represent the variance between options
Option 1 = Design iterations of a user story are done prior to team sprint planning
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team that will be part of the next engineering sprint planning session
  4. Iterate with Design until each user story from the first set is ready with all required information for engineering to begin
  5. Product Owner presents the user stories along with lead Designer at the engineering sprint planning session
  6. Sprint commitments are made on which stories engineering can complete in the sprint
  7. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  8. Design and Product continue to work on the next set of user stories during this sprint that will be presented at the next engineering sprint planning session
  9. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance
Option 2 = Design and Dev of a user story is done in same sprint
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team and the Tech at the same time during the sprint planning session
  4. Sprint commitments are made on which stories Design and engineering can complete in the sprint
  5. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  6. Design and Dev are done in parallel on the same stories during the sprint
  7. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance

Early in the discussion, most people were already on board with Option 1 but we continued to discuss examples so that we all understood how it would play out in the day to day ceremonies that our teams already had such as Release Planning, Sprint Planning and daily stand ups.  We agreed that leads from Product and Design would continue to attend the sprint planning and daily stand ups as needed by the team.


Yes, We’re Agile but we still Plan, right?

Yes, of course you still need to plan – even when following some type of agile method. It still amazes me that so many organizations stop doing this. Some don’t it because they believe that agile means no planning and some don’t it because … well, there are so many other reasons. Is it really worth repeating?  Maybe I’ll do another post about that, but for now, let’s look at one team established an intake process for new projects and made it simple yet effective.

000 Blog Agile Topic Photos - 10


Before our teams begin working on new projects, we need a way of ensuring that there’s a solid business case to do it and a clearly defined scope of features or benefits.  Sounds like planning right? Well, you could say that but, actually it’s before we even start really planning; we’re evaluating, we’re justifying, we’re using the ROI (Return on Investment) model to ensure we are pursuing the right project in the right order (priority).

Let’s look at the scrum model for a moment.  Each sprint starts with a fully formed group of user stories in the backlog that are “ready” for the team to start working on them right?  Well, how do you know that those stories are really the right ones to pick up next?   We started by tracking backwards from the backlog to build a process the supported how we were working and kept us in an iterative learning state of mind.  The image here shows the process or workflow that we are using.

The Product Owner is constantly evaluating current progress against the backlog of new ideas.  Once they have something to present, they prepare a proposal that includes key data points of their research and ideas in the form of business justification and benefits to the company and our consumers. We ask for 1-3 sentences describing the end result of the project.  It should address questions like “Why are we doing this?”, “What is current problem statement or potential improvement and what is the expected outcome at the end of this project?”  Along with this justification, we also ask the Product Owner to detail the benefits to the company and/or our consumers by providing either target or concrete goals for the project that fall into categories like Cost Reduction, Revenue Generation, UV Lift, PV Lift, Brand Lift or Efficiency Gain.

This provides everyone reviewing the proposal a clear understanding of the why they may want to approve the project to be approved and funded.


If a proposal is approved, it is moved to a “Committed” state where the teams involved do a release planning session so that all the impacted teams (internal and external) are able to evaluate the size of the work and the interdependencies between team as well as other projects that my have higher priority to agree on a projected start date, completion date and estimated cost.  Those data points are provided back to the approvers to ensure that the ROI is still positive.  If everything still looks good, we move the project to “Ready” and each team picks up user stories from the Product Owner for their sprint planning sessions.

Not every project begins immediately after the release planning is completed but we try not to allow too much time between the session and the project actually starting.  There are cases where a proposal is approved but it’s low enough on the project priority that it could be months before we are able to start working on it so we delay the release planning to be closer to the start date. We move the project to “In Flight” once work begins and place it in “Deferred” status when and if the project is put on hold.

Notice that even after a project is moved to “Complete” it’s not all the way through the project workflow.  This was an important step in  iterative learning and decision making that we added after a few months running the projects through the workflow.

Some of our project leads were reporting that even when the final production installation was completed, the benefits that were expected from the project would not be true until several weeks or months afterwards.  And no one was going back to evaluate the results of the completed projects to verify that the benefits had actually been achieved and to what degree.  That was the beginning of our Project Retrospectives.

If you think about how Scrum teams do team retrospectives to determine what changes were working and which ones weren’t it makes total sense that as a business, you’d want to do the same with projects.  Every month, we began retrospecting about each project that was completed in the prior month.  The team members were encouraged to present the results and we started to see improvements in several areas not just in the new project submissions but also in the cross pollination of product knowledge across the organization that did not have a venue in the past.  People were curious about why we were doing certain projects and now they had a space to hear the results, see the bigger picture and feel how each of them were part of the overall goals.

Once we completed the retrospective for a project, we move it to “Benefits Realized” adding the results so that we can reference it in future project proposals. Here is a template that was used for each project retrospective.  Note that our company uses the capitalization accounting practice so it’s also evaluated.Image

Agility is about the ability to react quickly when necessary and appropriate.  So yes, we plan and we are still Agile.  We use the intake workflow to keep us in the cycle of learning and adapting.  We’ll likely make adjustments as we evolve as a team but for now, this is reminding us to keep watching if we’re going in the right direction and allow the agility of the teams to respond as we learn and adjust our business roadmap.

Trade Your Wasted Efforts for Tactical Plans

Frequently I have blogs, articles or emails sitting in my box for weeks before I have time to read them but when I do, it was at the right time for me to read them.  One of those articles surfaced in my mailbox today and it was yet again, perfect timing.  The article was from Martin Yate where he explains “How to ace the world’s toughest interview question” and while it would seem perfect for someone looking for a job, I read it with a different lens.  I was looking at it from an angle of focusing on what I want to do and making sure that everything I spend time on is directly related to doing it.

Your job exists to help your employer achieve and maintain profitability. How do your efforts support these goals?”

This is the first sentence Martin writes that caught my attention because I’ve been doing Product Planning and Roadmapping with a few different teams over the past few months and this is how I think of the relationship of stories/requirements to the Projects we plan and the Projects we plan to the Goals for the year.  I ask each Product Owner to understand their stakeholders and managers goals for the year and turn them into actionable goals of their own.

You need to think through whether your job is chiefly concerned with generating revenue, protecting assets, improving productivity in some way, or is perhaps a combination of these imperatives. Once you have determined this you have also outlined the correct framework for your answer.”

Too many times, I see work on a backlog or even on the story board already in progress that cannot be clearly mapped to the goals we agreed upon.  Taking this approach to building your Product Roadmap and settling on a plan can help you eliminate wasteful time spent on things that are not going to get you any closer to claiming successful completion of your goals and hence, your leadership’s goals.

%d bloggers like this: