Skip to content

Combine Create timezone groups' UJMs

🗺 Group UJM murals

🧐 Observations

  • The Execution stage had the most action stickies and the least amount of questions/concerns. Do we really understand it well or are we missing important parts?
  • There were repeated questions about the boundaries of the journey, which is defined by the JTBD. Is this JTBD at the correct altitude? Is this really such a big job?

👎 Least confidence

These are the areas that the groups were not so confident on and that they would like to validate.

General

  • What JTBDs usually take place in the Before and After phases?
  • What happens in these stages?
    • Pre-execution stages: Define, Locate, Prepare, and Confirm.
    • Conclude (“End the job, wrap-up, and follow-up”)
      • Action: Create follow-up issues as needed

Maintain development environment

  • Action: Update dependencies/GDK as needed
  • Action: Resolve GDK errors
  • Negative feeling: Just want to get working but have to battle with GDK
  • Pain point: Maintaining my dev environment is such a pain - there is always some dependency out of date.
  • Is this universal to all moderately-complex codebases/environments or is this limited to our GDK? How often do other organizations have similar problems with their “GDK”? Do most developers experience this often?
  • Most READMEs are about helping people set up and contribute. This is very important for open source projects.
  • Do developers do these things every time?

Stay up-to-date

  • Action: Monitor emails for alerts of feedback.
  • Action: Inform reviewers of changes through comments.
    • Maybe we need to research how other teams communicate between them.
    • Kai: I don't have low confidence on notifications in general, but rather the specific notification types and signals, where, when, how.
  • Action: Monitor deployment.
    • Negative feeling: Confused; how do I know when it's in staging/production?
  • Opportunity: Notifications when code is deployed to environments.

Understand code base

  • Step: Locate appropriate location to make changes to.
  • Pain point: Finding similar pieces in the codebase might not be straightforward
  • Pain point: Need to clone repo locally to search the code line.
  • Search capabilities are lacking today, compared to local environments/IDE.

Plan

  • Pain point: Estimations can increase unnecessary pressure on my team.
  • Pain point: Hard to figure out team capacity.
  • Negative feeling: Don't know what we don't know to properly scope.
  • Action: Add weight to issue weight in sidebar.
  • Action: Weight the effort based on past throughput and LOE.
    • Amy: important problem, the TW team specifically struggles with this and making this work for us.

Know my work stream

  • Opportunity: Improve global overview of currently in-flight tasks
    • What other opportunities, other than a dashboard, do we have to improve findability.
    • MRs that I'm a participant.
  • Opportunity: Improving what did I work on view
    • The activity/heat map view is used for this but it's not fantastic, especially if there's a lot in one day.
    • Difference between subscribing to new activity vs. interacting with an object.

➡ Recommendations

To move forward and build one or more research-based maps, we need to do more investigation. Our recommendations, in order:

  1. Validate the JTBDs for Code Review. In particular, looking at the JTBD that was chosen for this exercise to understand if it's at the right altitude and properly phrased.
  2. After the JTBDs are validated, we should be in a better place to answer the general questions.
  3. Depending on what we've learned, we may need to dig deeper into the other least confidence areas.
Edited by Pedro Moreira da Silva