Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Scrum Board

 

All the states from To-Do to Done from overall workflow were configured as part of this execution board. In-fact, team started with UAT state as part of each sprint initially, but due to unavailability of users, team improvised the flow to reflect business realities. By having DONE column before UAT they were able to close sprints on-time.

To address UAT challenges, separate UAT board was created.

UAT and DevOps

All the Stories which were moved to DONE(once it passes through dev, testing and demo) were pushed to UAT(board). This board gave complete view to end users to see all the things they have to test and gave visibility to DevOps to push UAT completed tickets to Live. PO worked really hard to work with users to get the testing done sooner to keep the queue small. As you see Team used Kanban flow and used control charts to measure cycle time aka business folks availability and PO’s leadership to move things from UAT to Live!

This was a specific use case. You can configure these boards and workflow as per your needs to provide visibility and to streamline your approach to attain FLOW.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
Gaurav Handa July 27, 2016 at 7:31 pm

Avi,

It is indeed a great way to accomplish and in fact we have been practicing it in the same manner in our projects. We have few long term projects where we are rolling it changes on the UAT environment and since the client is busy with other business stuff, we don’t get the feedback on time. We have changed our definition of doneness by moving the items to UAT stage and any feedback received during UAT is then moved as a separate item in the PB to ensure closures.

Avienaash Shiralige July 27, 2016 at 11:52 pm

Great to hear that!

Abhishek July 28, 2016 at 2:57 pm

@Gaurav you mean moving the items to UAT is ready for UAT and not UAT done. Correct?
We are doing a little bit same what Gaurav mentioned above. This is product call to define whether they want kanban or a different collaboration/tracking tool to get feedback from end users and report a respective improvement if any or follow-up task or issue into the product backlog to take in subsequent sprint for some further development. Most crucial part if active collaboration with all stakeholders and transparency which is required at all levels otherwise no agile model is going to work be it a kanban, scrum, xp etc.

Milind Kulkarni July 31, 2016 at 7:54 pm

Hi,
I am very much agree with Abhishek. Crucial part is collaboration between stakeholder and transparency at all levels.
But for long running project , particularly in banks we often end up in scenario the PO will not be able to complete UAT in sprint. That is where the Kanban board will really help. Kanban board works like information radiator and help the stakeholder to identify the pending items for UAT. Thereafter stakeholder should them self identify the WIP and speed up UAT.

Comments on this entry are closed.

Previous post:

Next post: