23 May 2016

Blog Scrum

Scrum is a great framework! I love it! Scrum and I have endured our up’s and down’s, like I’m sure is true for most practitioners. No matter which project I’m on that’s using Scrum, either if I am the Scrum Master or coaching, one thing that is very important to me is how we track our progress on sprints visually. Whether we use TFS, Jira or whichever Agile Project Management Tool (It could be Excel for all I care), I much prefer to use an Analogue Scrum Board, in the middle of the office, where everyone can see it.

Tools, such as the ones I mentioned above, are great and they serve a great purpose, especially when you have an application with auditing requirements and need to have complete history of all changes or working with teams that are remotely based. But nothing…and I mean nothing, beats the physical Scrum board. I want to share with you my top 15 tips and techniques to having an effective scrum board (some of these tips could also be applied to a Kanban board).

PLEASE NOTE: These are in no particular order, I attempted that exercise and determined I couldn’t decide which tips were more important

User Stories / Defects / Technical cards

1. Place holder for conversation

Remember… User Stories are just placeholders for conversation. That’s one of the main reasons why we write them on Index cards. They must be readable and clear. As my readers know from my Previous Post please…. PLEASE… refrain from just using the tools tracking Id. We’re not robots and do not have the entire backlog catalogued by Id in our heads.

2. Who’s doing what?

Making the board as visual as possible is such a great aide. One technique the teams I coach like to use is printing out little pictures of each of the team members and sticking them to the story when they are being worked on. Your tool will probably do this easily too. If you are feeling extra creative and to make things a bit more fun, you can use the team member’s favourite actors or football players. :)

3. Highlight blockers

Use stickers to highlight when Stories are blocked. Using a big red dot on the story is a great visual when highlighting that there is an item at risk from not progressing. When the blocker is resolved stick a green dot on top of the red dot.

4. Differentiate work

Use different colour index cards for Stories, Bugs, Technical Work and Spikes to differentiate the work. This seems obvious, but if you don’t do it then the type of work on the board is hard to interpret. It’s a great visual for the Product Owner also so they can see how much new value vs business as usual is in the sprint.

5. Highlight work not moving

Work that’s not moving on the board can quickly become a problem. I have seen teams that are ok with this and are not as concerned with work not moving. This kind of attitude can hurt delivery as stories will start to fall in to the following sprint. A good way to keep on top of what needs to be delivered is to keep a tally of the number of days the story / task has been in progress.

6. Highlight work that’s in production

If you are a team that strive for continuous delivery and deploy several times during the sprint, it’s a good idea to mark which stories have been shipped already. I have found it to be a good motivational technique. In some cases, we have used a smiley face on the story to indicate it’s been shipped. Get creative here!

The Scrum Board

7. Visible

Make the board visible. This is the most important tip from me. Even if you use a tool such as Jira, replicate it on Index cards. It’s not that much effort to keep the 2 in sync. When we were using VersionOne a few years ago, I built a small add in that would print off the stories on index cards. I believe that feature exists now, so if you can’t be arsed to write them out, then print them.

8. Keep a key

With colour coded index cards and stickers on the board, it’s a good idea to keep a key of what they all mean. Being transparent is one of the important factors with Agile methodologies, meaning anyone, including the senior stakeholders, should be able to swing by the office and look at the board. Having a key is useful for people who are involved in the project but not committed that want to see what’s going on.

9. Sprint burn down

I have worked with people who had thought burndown charts were just for stakeholders and project managers; they’re not. It serves as a good tool for the team to see their current position in the sprint and determine whether they are on track to delivering what they committed to. Keep the sprint burn down chart up to date and next to the board so everyone can see.

10. Retrospective actions

“If you’re not having retrospective’s then you are not being Agile!”… I said this once, OK, maybe I have said it several times to teams in my organisation. In my honest opinion, the retrospective is the most important ceremony in Scrum. It’s an opportunity for the team to learn from experiences and improve. Actions usually come out of retrospective’s but don’t fall into the trap of typing them up in an email and sending them to the team or worse still keep them on a shared drive or SharePoint because NO ONE WILL LOOK AT THEM!. Scribe them up and keep the retrospective actions up next to the board where everyone can see them and be reminded of what we need to change as a team.

11. Sprint goal

Hopefully, the stories you commit to in the sprint are grouped in similar areas, so much so that the Product Owner and the Team has been able to determine a Sprint Goal. I understand that’s not always possible but it’s great when it is. I find teams tend to be more focussed and cohesive when a Sprint Goal has been determined. Therefore I like to keep the goal written out in big and stuck right above the board.

12. Velocity

I’m on the fence with this one. I have worked with team’s who wanted to keep the velocity visible next to the board and have worked with teams who didn’t really care. If we look back to the point I made earlier regarding transparency, then it make’s sense to make it visible. Velocity is a key metric and tool to give the team a rough feel as to how quickly they are moving. The trouble with velocity is that at the beginning of the project I find that this number fluctuates a lot until the team finds a rhythm.

13. Define the columns

I find it very useful to define what the columns mean to the team at the beginning of the project. I have never been on projects where these are always the same. If you are in the middle of a project and you haven’t done this then I recommend you do. Getting the team to agree on what each of the columns mean is useful to remove any ambiguity. What Ready and Done means should be clear and consistent. Making these definitions visible will help with that.

14. Secure items on your board

This sounds like a silly tip, but if you are using post-it notes then don’t rely on the adhesive that’s on the post-it. Use sticky tape as well. Just relying on the adhesive is not enough, on warm days they will peel and fall off, leaving a nice pile of un-organised stories on the floor! :’(

15. Roughly map out backlog and future sprints

Lastly, and by no means least (this is probably my favourite tip), I really like the idea of roughly mapping out the next few sprints. Many productive short coffee break meetings have been had around the future sprint work board with the product owner. It’s good for the team to visually see what the product owners priorities are (not just in the Agile tool you’re using) and when the team will roughly get to them. Nothing feels better than to physically grab stories off the board and move them to shape the roadmap of the product. I also like to keep a heading above each column like the image below to highlight the sprint the piece of work will be in and I also like to keep a marker for key dates or milestones the team needs to be aware of, i.e. a release of a dependant system that might impact your project.

Bonus Tip

Here’s my last tip that I was reminded of when I was looking at the board this morning. Put a BOLD border around the board (make it red if you can)… why? It’s a good visual reminder that no changes should be made during the sprint, especially for the Product Owner ;)