Kanban physical board and Jira/VSTS board - Duplication?

There can be duplication of effort if you choose for it to be  My organization uses Jira.  We manage our stories in Jira by creating them, tying them to Epics, managing the product backlog, creating a sprint and sprint backlog.  But when it comes tasks, we do all of that on a physical board via post-it notes.  We will transition the story in Jira as it is worked on the physical board. We will print the story cards from Jira and tape them to the board instead of hand writing new cards for each story. We try to split the work managed virtually and physically as much as possible and where it makes sense to do so.

We have found that having the tasks managed on a physical board has some benefits. It is easier to remove or add when using post-it notes.  There is a psychological benefit of moving a physical item through the process and being able to easily view the entire sprint's activity in a single glance. Gathering at a physical board for the Daily Scrum will also make any conversations that need to occur easier. 

This all depends on having co-located teams.  If we have any remote team members, then we revert to using only the virtual boards in Jira because trying to include a remote member into a stand up at a physical board is difficult and we haven't found a good solution for that. 

Have I understood the process correctly? Am I missing something?

In agile practice, the team ought to own its process, and be able to account for and to improve its implementation. Have you asked other team members why two boards are being used?

Thank you guys very much. I think I still don't understand fully :-( so epics stay in jira but tasks are duplicated and written again on post it notes. Here I understand. But if you hand write the tasks why the need to print them? And after every stand up you go back to jira and update the tasks,right? Or on the post its you only have the title and number and no other details? So you just move them access the physical board and provide update verbally and that verbal update is updated in jira?

My team doesn't own the process yet as we all are new to agile and I'm training them. I've done my agile training certification some time ago so I have some theoretical knowledge but now when I'm trying to implement it in practice I realise that I need help.

So thank you guys for helping me out.I appreciate it a lot!

What is the correct process? (step by step if possible please!)

As unhelpful as that sounds:  The correct process is whatever serves your team's needs in the simplest possible way.

The team I'm currently a part of has deliberately decided to use both a virtual and a physical board. The virtual board keeps remote members up to date, but it doesn't provide the same transparency (because you can't see someone get up from their chair to move a card across the board) and cause for conversation. So we opted to keep the physical board so that the co-located part of the team can reap its benefits. We found the trade-off between those benefits and the effort of keeping to boards synchronised to be worth it.

As unhelpful as that sounds:  The correct process is whatever serves your team's needs in the simplest possible way.

Exactly what Julian says. Let the team experiment what works best and reflect why this does or does not work. I've been with team that would solely use JIRA, other teams solely used Kanban boards and other teams used a mixture. Trial and "error". See what happens. Always be transparent about the expectations and what the expected outcome. Why do we need a board/tool? What happens if we don't use it? What do we need it minimally have in terms of functionality? 

To clarify my comments in Jira terms.  We put Epics, Stories in Jira.  We do not use Bugs, Tasks or Sub-tasks at all if we have a colocated team. All Story sub-tasks are written on post-it notes only and put on the physical board.  I print the Story cards only because it is a convenient way to tie Jira to the physical board and prevents me from having to write all of that information again.  

Jira is the source of truth for Stories and Epics.  Physical board source of truth for the actual work (i.e. sub-tasks).  We do not keep the sub-tasks at the end of the sprint because if we ever do another story similar, the tasks will be different because we now know more than we started. 

If we have remote team members, we do Epics, Stories and Sub-tasks in Jira.  

All, thank you very much, I think I now understand it much better. Some duplication is therefore necessary and both boards should be seen as ‘friends’ and not ‘enemies’ and if it doesn’t work we can always change the process. This is very useful.

One more question I have is about the colours of the post-its. Some people say that e.g. blue is for all items in testing and e.g. green for done. But in practice it would mean rewriting each ticket based on the progress which to me does indeed seem too much of a duplication effort- but again maybe I haven’t understood it at all?

I though you assign colours to different categories, e.g. feature 1 is blue and feature 2 is green and so on?

Thank you all again very much for all your help.

One more question I have is about the colours of the post-its. Some people say that e.g. blue is for all items in testing and e.g. green for done. But in practice it would mean rewriting each ticket based on the progress which to me does indeed seem too much of a duplication effort- but again maybe I haven’t understood it at all?

I though you assign colours to different categories, e.g. feature 1 is blue and feature 2 is green and so on?

There is no right or wrong way to organize your board if it works for you.

That said, what works for me and my teams is that each story/bug/task has it's own lane (row) on the physical board, much like you may see in JIRA. This way you do not need to use colors to show difference.

Here is an illustration of what I mean: 

To elaborate, each little square is a post-it note that would be the sub-task of the issue. It is however the team decides to break up the body of work. You may find it useful to have a sub-task that says "testing" or "code review" that you can move to "In Progress" rather than having to color code when a piece of work is in test.

I'm going to quote one of the Principles found on the Manifesto for Software Development.  It is found third from the bottom.

Simplicity--the art of maximizing the amount of work not done--is essential.

Since you are creating tasks why not make it obvious if it is a testing, coding tasks by the words on the post-it?  What I've found is that the color coding starts to become problematic as you find yourself doing different things.  And remember, Scrum does not recognize titles within a Development Team.  It is basically a task that the Development Team needs to accomplish.  But ultimately, ask your team how they want to do it.  They are the ones that will use the board to manage their work. They should be the ones to organize it as they feel necessary. 

Oh one more problem with the color coded post-its.  Sometimes yellow post-its from different vendors are not the same color.  Some OCD people really have a problem with that. (just saying). 

I forgot to put this in.  

You are referencing a Kanban board.  That is different from the normal Scrum board.  But using a Kanban board in Scrum is something I advocate from time to time.  In your example, I'd have columns to map your workflow.  For example:

| To Do | Coding | Testing | Review | Done |

I made that up but you can do what makes sense for you.  To map it back to Jira for your Stories, a story will be waiting to be worked on (To Do), being worked on by one or more members of the Development Team (In Progress) or Finished (Done).  You would have multiple columns on your board that indicate the In Progress state. 

My team doesn't own the process yet as we all are new to agile and I'm training them.

Why does that stop them from taking ownership of their process now? Is there some other authority telling them how to do their work? How did this two-board situation arise, and upon inspection do the team think it is worth continuing or should they make an adaptation?

Thank you all. It's a pity I can't reply individually to each response. I think I now understand the colours and once we have a board (yes! we don't have it yet but it's being ordered) I think I'll start simply with one colour per developer and if it doesn't work we'll change it.

Unfortunately the team (for now) is used to take 'orders' and deliver in a waterfall way. They are new to agile concepts like taking own initiative. I am working on changing this culture but it will take time. An additional problem is that I don't have a full time team and it's very small - 3 very 'junior' developers, 1 UX and 1 solution designer. In additional they work on some fixes and other waterfall projects. So I am sadly introducing Agile to a team and a department that is very waterfall, full of processes and many many approvals.

An example of a problem is that business comes with a problem/project proposals, explains all to architects/solution designers and expects them to first write a 3 page long document to summarise top proposals, next they want a concept so something visual, and the third requirement is to write a detailed solution proposal - 20 -30 pages! And all before a project/solution even gets approved. So if the solution is rejected all this documentation is needless.

My problem is to come up with some sort of a visual design that provides all the high level info about the solution and then if business likes it we can start delivering in increments. Do you guys have this sort of process where you work? If so do you have some suggestions on how to deliver a HL solution proposal without the need to write long word documents? I can't just tell them: no we won't give you those 3 documents! I need to tell them something like: here is what you are asking for but in a different format.

Thank you again so much for your help. I think I would go crazy on my own without your help!

once we have a board (yes! we don't have it yet but it's being ordered)

Going to start with that one.  Why order a board?  All of our boards are a big open wall, blue painter's tape (because it can be removed without peeling the paint) and post-it notes.  That is very low cost and easy to remove or change if needed. A tip, use big post-it notes to label the columns.  Each row is for a story.  Make the To-Do and Done columns the widest.  Keep the In Process columns narrow to subconsciously help the Devs limit the work-in-process to provide focus. 

Ok, here goes my opinion on your document situation.  I'm going to use a quote from an Agile Coach that I respect a lot.  I'm not applying in the context that he usually does but in this case I think it fits.  When you are building up all of that documentation you are "planning at your dumbest point".  The concept is that you can plan a grandiose system that can be delivered in 3-6 months.  But a lot can change in 3 months in business these days. So how do you know that what you planned will still be needed when it is finished?  Agile is about starting with a problem that needs to be solved, deliver a portion of the solution, let the stakeholders see/use it, get feedback from them, adjust what you are building. It may take you more than originally planned but what you end up with is actually what the stakeholders/users want and will use at the time you are finished. 

So how do you get them to realize this?  Basically I'd ask for them give you a chance to experiment and prove the worth.  Work with them constantly during the process and be hypersensitive to their feedback.  Ask them to define a problem, work with them on the initial goal.  This could be your 3 page document so you can still use a portion of their process.  But from there, you start Scrumming.  Your first "visual" is the result of the first sprint. Then you continuously give them visuals building on the first one and incorporating their feedback in each subsequent sprint.

Hi Daniel and all, I am so sorry for the late replay but it has been crazy recently.

We stared the first sprint and used both Kanban boards. The team likes the physical one but it seemed to be difficult to update both so basically the VSTS one was not updated. The team really like the sprint and the new process so I didn’t find it to be effective to chase them to update VSTS, I let them do what best suited them.

Thanks for the points about the documentation, I totally understand it and some of the team members do as well but designers seem to struggle with that. I think they have been doing it the waterfall way for too long and just can’t imagine how a system can be built based on high level designs. At the beginning of the sprint they started going into details such as measuring the cm of a column on a screen. I did my best to explain but I failed :-( next week we start another sprint so hopefully it will go better.

Is there a forum specifically or UX or/and system designers so that I could ask my guys to use it to get a different view/perspective to what they are doing?

During the sprint we didn’t document anything, we got requirements from the business owner, split them into stories/tasks and just concentrated on delivering them.

At what point in Agile do you start to document your product? And what is the best format? Word? Should the documentation be like waterfall but with less details? If so which details to omit? E.g. in a system design document what information would you put?

Thank you again very much for your help :-)

Ps. If I change a subject of my thread should I create a new thread of continue with this one? Sorry but I’m totally new to this forum.

Hello Ana, I can understand your confusion. My team is distributed globally hence manages their user stories and tasks in VSTS to maintain transparency. Everything is visible to everyone. If you want to eliminate manual effort then go for JIRA/VSTS. It is easier to create and maintain PBIs online.

I hope i could clear your doubt.

At what point in Agile do you start to document your product? And what is the best format? 

When you create your first story in Jira, you started to document the product.  

Now, I'll try to really help you.  :)   What is the purpose of the documentation?

Ask your identified stakeholders what they need.  I would suggest you start documenting it based on the first increment that is delivered external and continuously update based on any new increments. 

What goes into the document?   

E.g. in a system design document what information would you put?

I'd put the design that has been implemented because you don't know what the design will be in the long term.  The best designs will be created organically and iteratively as the product evolves through the iteration process.  Do not document anything that isn't delivered to the stakeholder.  The review of the non-released increments will occur during your Sprint Review and any other (hopefully frequent) interaction that you will be having with your stakeholders. Remember that in Scrum/Agile, you don't know what you will be building, only what you are building.