The card wall should:
A well-executed card wall will provide the following:
#Why is card wall management so difficult?
Because it is not easy. Well, that seems like a dumb answer, but an answer non-the-less. The management of the card is inherently difficult because there are so many moving parts. Any good card wall will have the complete status of the team at any given point in time. For instance:
But, why is it so difficult? We have still not answered the question. It is hard mainly because the team needs to get on board with the purpose of the practice. The card wall is not there to make your life difficult. It is there to make things big and visible, which can be painful at times. But, there to, in one spot, show all of the teams successes and challenges in the same spot, at the same time. Sometimes, people do not like for everything to be ‘out there’ where everyone can see. Stop making a big deal about what you do not want to show the world and use the board to accelerate teh team to a new level of productivity and success.
#Why to teams make the card wall such a constraint? I do not know that I have the definitive answer to that question, but I can speculate. They are scared of what information the wall will present to the outside world. If the card wall is a mess and the outside observer (whether a passer-by or your manager) attempts to read the board… the confusion will limit their ability to decipher. Please stop doing this. A well-executed board will allow the status of the team to be bigger and more visible. You are more capable of recovering from a bad situation when the rest of the team knows the issue and can react and provide assistance.
#Who should own the wall?
###the Scrum Master?…
###the Technical Lead?…
In my world, the card wall is owned by the team. The business is responsible for putting cards within the backlog… in priority order. They should add/remove/rearrange as much as they like. As soon as the card is removed from backlog to the ‘in progress’ column, the business has lost the card. If the business decides a card, already in progress, needs to be postponed or cancelled… the team takes the points and gives the card back to the business. If the business decides the card needs to be placed back in to the backlog (at some point)… reestimation needs to occur. This is not to be considered a point collecting exercise, but the cost of context switching.
There are an infinite number of possible layouts, and should be determined by the team. Here is a basic layout I would start with.
|Backlog||In Progress||Ready to Test||Tested||Ready to Demo||Accepted|
#Backlog Cards that meet the ‘definition of ready’ (defined later). But in general… cards that are well defined, thought out and ready for someone to work… NOT cards that are blocked in some manner. NO Missing Acceptance Criteria !!!
#In Progress Upon entering this column… an entry conversation should occur. I will leave it up to the team to define the participants, but the entry conversation is key and should not be skipped. Many teams call this entry conversation… the ‘three amigos’ conversation… a developer (pair), a tester and a product owner… or some similar combination. After this clarifying conversation… the card can actually be considered ‘in progress’.
This column should be where all of the cards, that are currently being worked on, are located. A reasonable WIP should be defined and all cards currently ‘in progress’ by the team should be in this column. This means everything (every user story). If a team member is working on ‘something’… that ‘something’ needs to be put on a card and placed in the ‘in progress’ column. When a team works on tasks outside the scope of the team space and are not managed on the wall… therse are generally the teams that never meet their commitments or the team that is continually finding themselves in the middle of a death march.
#Ready To Test Development has completed the user story… test driven of course… and verified all of the acceptance criteria are met. This might (should) include sitting with a tester and verifying the user story is delivered as requested. The user story is now ready to be picked up by the testing team and verified… not on a developers machine, but the testing environment… the environment the application is automagically pushed to by the continuous integration process.
Let’s work from left to right.
#Some Key Concepts Associated with the Card Wall
##definition of ready this is a tough one. The definition of ready should be ‘what’ the team agrees upon as a litmus to determine if a user story is ready to be worked by the team. A user story should not (and in my world, can not) be added to the groomed backlog until all of the terms of the ‘definition of ready’ have been met. Skipping, or worse… ignoring the DOR can cause lots of problems. Here are a couple examples of what might be contained on the DOR…
##dots on cards This is a personal one. I like each team to put small indicators on each card at the completion of standup each morning (or whenever you have daily standup). Each column on the card wall is assigned a different color indicator… including a way to mark the occurence of stand up and if a card is blocked at the end of standup. For example… if a card is moved from ‘backlog’ to ‘in progress’… at the completion of the next standup… a ‘red’ dot would be placed on the card (if the card was still in the ‘in progress’ column). Each column is treated the same, but with it’s individual color. These dots allow for the daily analysis of which cards are stalled and which cards need assistance. All of the cards should be analyzed in order to determine patterns over time.
##names on cards This one seems pretty straight forward to me. Each card on the wall should have a pair of names (you are pairing… right?). The names are a great way to know who to ask when you have a question about a card. It also helps to know when someone needs something to work on. Also… it helps to know when someone is violating the teams WIP limits. Please put names on the cards.
put the excursus definition here
This one is mine… I invented it. The ‘EXCURSUS’… a divergence from the main point of topic… or in my mind… ‘things’ you want to talk about after the standup is complete. These can be…
##swim lanes (WIP) If you find yourself in a team space where the team is unable to manage their work in progress… introduce a swim lane. If a column on the card wall has been limited to a certain WIP limit… divide the column into the same number of sections and only allow each section to have a single user story at a time. The team will first push back, but it will be very visible when the WIP limit is being violated.
##days remaining Pretty simple… the number of days remaining in the sprint. It is nice to be able to look at the board quickly and see how many workable days remain.
##expected / accepted Another pretty simple one, but powerful information. Expected number of points to be completed by the end of the sprint… and the number completed. This one really works with the ‘days remaining’.
##business backlog (ungroomed)
##talk to the wall Each pair on the team should speak to the cards on the wall. This forces each pair to only work on ‘things’ that are being managed by the wall. It also allows the rest of the team to remain focused on which column the cards is currently contained and if the pair needs immediate assistance to complete the card.
Let’s talk to wall from right to left and bottom to top.
##drag cards Cards should be added to the card wall… when someone on the team is pulled from the team space to work on something else. Any work, completed by the team, not directly associated with the team (production support, helping another team, etc.) should be put on the wall (hours are fine). These cards will allow for the proper analysis (at the end of the sprint)… especially when the team commitment is not met.