WalkMe Work Tracking with Kanban

Intro

If you've used WalkMe for more than a few minutes, you've seen that the WalkMe editor does not really facilitate tracking of work.

It shows draft / published / etc, but not really well who is doing what or what is planned / actively being worked on.

Folder structure of DRAFT/WIP/PUBLISHED can help but doesn't get very far.

This is why in initial Enablement, companies are presented with an Excel "Book of Work" file to capture projects.

But customers don't stick with this for very long. Once teams progress past the initial implementation, they begin to track WalkMe work in their own manner. 

One of the popular approaches for this is some kind of a Kanban board in a digital tool:

If you wanted to do this, how would you set it up?

And does this make sense in the long term?

Let's dive in.

Configuration for Kanban Columns

One strength of using a Kanban board to track WalkMe items is that the configuration is fairly straightforward and can be tailored to your unique circumstances.

Let's look at a basic Kanban starting point:

Backlog

• The very first column is the easiest.  This is where any idea or request comes in.
• Example:  We should have a WalkMe for xyz on this page.  What about adding this data to IDP?  Add a shuttle for XYZ.  Fix this display issue, etc.
• When you start to have more than can fit on the screen, you can typically drag and drop up and down to establish a rough priority.

Breakdown/Specify/Scoping

• Instead of having the next column be "Work In Progress", I recommend a column to detail / figure out / scope what's meant by that task.
• If the issue is a bug / defect / display issue, you can proceed on a more expedited path.
• But for user suggestions for Walkthroughs, typically we need to look into it to determine if it's really necessary, what's the best way to solve the issue, what other content is impacted, etc.
• Possible metadata: Title, Description, Application, Requestor Dept, Area of Application, Anticipated Content type, Time-Critical YES / NO
• Example:  Explain using new field being added in Q2, Salesforce / Sales Enablement / Opportunity / ShoutOut, WalkThru / Time-Critical=YES
• The "Done Rule" for this column is that we KNOW what we want to develop in enough detail that we could assign it to someone on the team to open the Editor and put it in place.
 

In Development

• This column specifies that someone on our team is actively developing WalkMe content.
• If items dwell too long in this step, did we actually have it scoped?  Are we overcomplicating the solution?  Is my WalkMe builder not as proficient as I'd like?
• Or have I not established my "Work In Process" limits correctly?  Or does my WalkMe builder have a bunch of other assignments not related to WalkMe?
• The "Done Rule" is that the item is ready for QA.

In QA

• This column specifies that a work item is going through typical quality checks.
• Browser compatibility, copy, segmentation, etc.  The checklists provided by WalkMe are good in this regard and you may have additional points you've added based on your situation.
• The "Done Rule" is that the WalkMe content has passed all your typical QA checks and has been pushed to production.

Validation?

•  Many WalkMe customers will publish to production then use Segmentation to temporarily expose the WalkMe content to a limited audience. 
• This allows for a "preview" and final confirmation to certain stakeholders prior to full production.
• I endorse this practice with the caveat that you don't want this to be the only time you've shown / discussed this with the stakeholder.
• If they mention something offhand to you once and then six months later you show them a fully baked piece of WalkMe content you've spent a couple of weeks on, that's not a good practice.
• You'll want to use your "Specify" phase as a way of getting detailed understanding from the stakeholder.

Published to Production

• This column represents the final step where we've delivered value to the end customer.

Where These Go Wrong

If you are in the "Total Chaos" state of the work tracking continuum, a kanban is a step in the right direction.

But it's good to keep in mind where these can go wrong.

One weakness of using a Kanban for WalkMe work tracking is that the cards are fundamentally not linked to the WalkMe items themselves.  If you implement a Kanban in MS Planner or Trello, you're essentially keeping two sets of books and manually linking card state to WalkMe content.

Tasks can get started and stuck when work happens that's not on the Kanban.

This is why the Organizational aspect is just as important as the Technical.  Establish a cadence to use and review the Kanban, discipline around not exceeding WIP limits, etc.

What's the right cadence?

This will depend on your organization.  Daily stand-ups in my opinion lead to rehashing the same issues.  Weekly is probably the minimum.

For More Learning

Agile Project Management with Kanban (Developer Best Practices) by Eric Brechner

Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis

Future Directions

Keep an eye on WalkMe software releases.  They may have something in store for teams to collaborate on WalkMe content...