Post-Its vs Agile Project Management Software

While some of the posts I’ve written recently, I’ve had a specific point I wanted to make, today’s topic is really about a current experiment I’m running and whether organizing our work digitally or with physical hands on artifacts is better. This is not anything new that I invented, and I’m sure countless thousands of Scrum Masters before me have done this with their team. This is just a placeholder for me to be able to look back in time and see things I tried or what my general way of thinking was and how that’s evolved; and hopefully I’ll generate some comments from you so I can learn about things you are doing!

Problem:

The team started missing sprint goals and carrying over work sprint to sprint, and the daily stand up did not seem to provide the transparency or accountability that a team ideally needs to help collectively move the sprint forward each day.

Said another way, while we follow the “Yesterday I did, Today I plan to do… “ format, the updates were extremely vague and it was tough for me as the Scrum Master to really tell what progress, if any, we made the day prior. In addition, the team did not hold each other accountable and stories seemed to drag on longer than they should be.

Looking at this bigger problem above, there are any number of potential reasons that these issues could be coming up including:

• Are the stories groomed properly? Clear Acceptance Criteria and Definition of Done?
• Are we committing to too much work each sprint?
• Are we facing impediments and not surfacing them?
• Does the team not trust each other enough to hold each other accountable each day?

However, the purpose of this post is simply to discuss one experiment I’m trying to help with the daily stand up piece. The other questions will have to be left for another day J

At CareerBuilder, we use Mingle as our Project Management Software and for the most part all of our teams manage their work with a digital scrum board, including both of mine. However, when reading Jeff Patton’s User Story Mapping and listening to speakers or reading blogs, a lot of them still heavily reference using physical post-its and having that information up on a visible wall. So I talked with my Engineering Lead and shared that one of the concerns I had with our missed sprint goals was the lack of clear direction and accountability in our daily stand up, and that I’d like to bring a physical sprint board into our area and move towards using post-it notes during our stand ups (see picture). He was on board and we brought it to the team, and we are now heading into our second sprint using this.

Our Sprint Board in preparation for our next sprint

Prior to this, we had user stories, but did not really task those user stories out. Since a user story on average can be anywhere from 1-3 days (some more, some less), it become a little too easy to talk about the same story for a few days without providing any real clarity on what parts of it you got done. For the last two sprint planning sessions, we are now taking our user stories, and instead of just having a general discussion on what needs to be built (which tended to include some of the technical things that needed to be done anyway), we are actually trying to identify and create as many of the tasks as we know about for that user story. We aim to identify ~70-80% of the tasks and we know we’ll identify more as we learn during the sprint.

At the start of the sprint, all of the tasks we identified go up as individual post-its on our physical sprint board. The way I’m coaching the team is that while a story can take multiple days to complete, if a task takes longer than a day, it means one of three things:

1.     We sat on our hands and did nothing the day prior

2.     The task is too large and should have been broken down

3.     We are facing impediments to getting that task done

When we come to stand up each morning and can’t move a task forward though, it at least provides a very clear signal that one of those three things happened and we need to figure out which one it was and work to fix it.

It’s been a work in progress and the first sprint was a little bumpy on understanding that it’s ok to break tasks down into further chunks. The main point of introducing the tasks was to allow them to break the work down into hour long, or 2-4 hour, or whatever chunks of work allows them to best organize their day and hold themselves accountable to the progress they are making.

It was very cool to see one of the Engineers walk over late afternoon on the second to last day of the sprint, and move along two task cards that wrapped up her story! I think when we do everything digitally, it’s a little easier to hide things than when you have a physical board right out in front of the team. But on the flip side of hiding things, it’s also cool that it’s a visible sign and cause for celebration when someone can walk up and move sprint goals along!

Feedback thus far has been positive and the team has agreed to at least continue on for a few more sprints. In general, they seem to like the visible reminder right in our area, because while they can ignore Mingle, it’s tough to ignore a white board right in front of them. I’ll try to remember to write a follow up on this after I see if we start getting the desired results.

One quick note, we do still use Mingle for tracking our stories; we just added the physical white board for our daily stand up meetings to discuss the tasks associated with those stories. I’m not as worried about tracking data on the task cards though so we don’t require those to be in Mingle.

Do you and your teams prefer just working with the software versions or have you tried the old school touch and feel of post-its as well?