Lean UX in an Agile Enterprise Organization Part 2

Looking for steps 1 and 2?

Step 3 – Build It

This is the Sprint and belongs specifically to the Agile/Scrum process.

Lean UX in an Enterprise Orginaization - Step 3

Once a Sprint begins all required mockups and/or prototype screens should be completed (No creating mockups during the Sprint). Since the developers are part of the initial review of the mockups there should be no UX surprises. The mockups/prototypes are reference documents for each of the associated user stories.  One rule that we follow is that the user story is the “final-record-of-truth“.  If there is any discrepancy between the mockup and the user story – the user story wins.   The number one culprit of this is content or label changes.  Often times the language of the content will change right up to the last minute before sprint planning based on the Business input.  We don’t expect our mockups to be pixel-perfect so we defer to the user story for last minute content or label changes.

There are however technical surprises all the time and that is what the little blue loops in the graphic above represent.  Thing pop-up and you have to be able to adjust on the fly.

We also utilize sprint playback sessions to make sure that the developers are implementing the designs as agreed upon.  This is another opportunity for slight modifications or tweaks to the mockups but often times these changes can be verbally communicated and captured in the user story.

Slight tweaks or modifications to the mockups/prototypes are acceptable during the sprint but if there are larger development issues with implementing the design then we have two options.

  1. The user story is removed from the sprint until the mockups/prototypes can be adequately updated.  I’ll admit that this is rarely done because the development team’s velocity would be significantly reduced if they remove the story and don’t have another story with the same assigned points ready to takes its place for that sprint.
  2. The other option is that the product owner and UX team will agree to implement a functional version of the design for the current sprint and create a new user story for the backlog that captures any UI or UX enhancements that should be implemented for a future sprint.  This can really help build trust within the team as it allows the development team to stay on track for their sprint commitment and UX can work with the business and product owner to take the UX enhancement story in for a future sprint.

We believe that UX should never impede development but we do request that our recommendations should always be captured in a user story so that we can prioritize those recommended changes for a future sprint.  This is where the relationship between the Product Owner and UX lead is critical to negotiate these compromises.

What is done?

  • Development
    • Ensure that New Features use Established Reusable UI Patterns – We use a UI Library that is specifically for developers.
    • UI Checklist – We have a created a UI Checklist for developers to refer to for standard UI patterns. This is basically a slimmed down Style Guide. How useful is this? Honestly it’s something we have to constantly remind our development teams to use and we rely more on the UI Library than the checklist.

Who is involved?

  • Scrum Team
  • UX resource


  • Normal Agile/Sprint

Step 4 Feedback

After the project is in production the next step is to incorporate feedback from our users and business stakeholders to drive iterative improvements to the project.

ux feedback

What is done?

  • Usability Metrics – One of the key areas that helps us in an Enterprise environment is that we have specific time measurements on the amount of time our users spend on each screen. This can help identify bottle necks and possible usability issues. One area we plan on exploring is to baseline current productivity metrics so that we can show overall increased value after new designs have been implemented.
  • Gather Business / User Feedback via user forums and interviews – We have various user groups that we stay engaged with to hear about issues that users are having.  Most of the time these issues are centered around business complexities rather than specific UX issues.  Its still good to be aware and identify if there can be some UX improvements to help the users. We also rely significantly on our training team to help consolidate issues users are having in the field. Our training team is a great conduit to our users and we rely on the heavily!
  • Update or create new Mockups and Prototypes based on feedback – this is where the fun begins. Let’s take what we’ve learned and improve the UX for our users for both current features as well as new projects that are on the road map.
  • Validate new Hypothesis Solutions – Always learning – Always Validating New Ideas!
  • Update Backlog with UX related enhancements – This is where UX starts to build that full circle engagement with Agile. Now, instead of UX only responding to new requirements we are establishing our own requirements. This is where the UX lead can leverage their relationship with the Business stakeholders to help drive up the prioritization on these new UX specific stories.  Getting Business buy-in is a huge step in pushing UX forward in an Enterprise organization.

Who is involved?

  • User Feedback
  • Training Team
  • Business Stakeholders
  • UX Resource


After release/ Ongoing engagement with users / Output should feed backlog



Lean UX in an Agile Enterprise Organization Part 1

Enterprise UX - Dave Landis - Lean UX - Better Together graphic

Dave Landis’ Lean UX graphic is well known and there’s a reason – it helps paint the picture of how UX work gets done within Agile. It’s a great illustration not just for UXers but Product Owners, Business Analysts, Developers and Business Stakeholders.

There may be better graphics but this is the one we use and it helps us map our groups and activities to the overall process.

We break out this iterative process into four main sections: Discovery, Hypothesis, Build and Feedback.

Step One – Discovery

A critical first part of the UX process is to understand the user need versus reacting to the user want.  This is accomplished through the discovery step.

Enterprise UX Discovery

What is done?

Identify Business Needs through:

  • Mapping Business Requirements to Business Value – This step is basically getting your head wrapped around what the business goals are and identifying the initial requirements to meet those goals. The key element from a UX perspective is finding the true business need vs. the business want. The business often times will already have a solution they think will meet their goals. That’s a good place to start but UX needs to validate if that proposed solution is really going to provide the value that the business needs.
  • Ghosting Sessions – This is where the UX team physically goes out and sits with our users to understand what they do today and identify potential improvements.
  • Brainstorming – Internal discussion of potential solutions within the UX team, Product Owners, Business Stakeholders and our users.  This is more focused on the what vs how.
  • Conceptualize Solutions – Lots of white boarding and mock-ups of potential solutions. This is really an extension of the brainstorming step as we now create some sort of visual artifact to generate discussion.

Who is involved?

  • UX resources
  • Product Owner
  • Business Analyst
  • Business Stakeholders
  • Users


  • This is done whenever a new request is generated from the business or product team.
  • This step happens well before Sprint Planning, Epics or User Stories are finalized.  It’s great if this is happening before backlog grooming or is separate offshoot of backlog grooming.  The primary intent is that this step is well before development and that it has enough lead time for the UX team to fully understand the current-state user experience as well as clearly identify areas where improved UX provides business value.


Step Two – Hypothesis

The next step of the Lean UX process is geared around creating visual artifacts (mockups/prototypes) of proposed solutions to generate feedback from all required stakeholders.  Often times this is what product teams want to start with.  They want to see mockups!  The problem is that without the discovery step those mockpus are built on assumptions and/or the product team’s understanding.  No one wants to build something the wrong way but often times a Business Analyst’s questions are more aligned with the business want vs. driving towards understanding the business need.  This is why UX discovery is so important and should not be skipped over.

The other critical aspect of the Hypothesis stage is that it is iterative.

  1. You have a hypothesized solution
  2. Build a mockup/prototype
  3. Get feedback
  4. Revise hypothesis … rinse and repeat

The cadence and time allocated to this step should be time-boxed so that there’s an agreed upon “deadline” that a solution is considered ready for development.  Depending on the scope and timeline of the project this can be anywhere from a couple of weeks to a couple months. The reality is that the product teams will want to give you a couple of days …. push back!!! UX needs time to build and validate.  Just as developers and QA need time to do their work, UX needs time to do theirs.

Entrprise UX Hypothesis

What is done?

Mockups and/or Prototypes are created to:

  • Validate Business Goals/Needs – pretty straightforward but this is to make sure that the business is happy with the solution we are proposing and if it aligns with their original business goal.
  • Identify opportunities for re-use  –  The Business and Developers love re-use because it lowers cost and reduces developer time.
  • Business / User / Developer Feedback – This is critical to make sure that all feedback is taken in to account and is also communicated across all stakeholders. This is where real alignment happens.  Developers get to push back on a specific UI pattern because it’s going to blow up their sprint with significant amount of extra work.  Business can prioritize that they “really” need specific functionality in release A and can wait on future enhancements for release C.  UX is responsible for advocating for delivering a highly usable product and not just a functional product.  In an enterprise environment you may have a user group that can actually participate in these sessions directly.
  • Usability Testing – The single greatest advantage that Enterprise UX has overall all other UX environments is that you have access to the users! This is where UX can leverage measurable usability testing metrics to support their arguments. The business is going to push-back with scope, timeline and cost. Developers will push-back with effort and number of sprints. UX needs to push-back with something other than “UX best practices”. If you can show strong metrics around efficiency and productivity with a good UX versus a poor UX – the business will listen.

Who is involved?

  • UX resource
  • Product Owner
  • Business Analyst
  • Business Stakeholders
  • Users (Usability Testing)
  • Developers


  • After Discovery
  • Backlog Grooming


How we use Lean UX within an Agile Enterprise Business Part 2