Tag Archives: scrum

The Power of the Backlog

The power of the backlog is incredible in a Scrum world.  If stories are the promise of a future conversation, then the mighty backlog can certainly start, end, or even influence a conversation.

The backlog can start a conversation … “Do you have it on your backlog?”

The backlog is a conversation starter when something new is identified as being a valuable enhancement to a given product.  Of course, value is generally subjective, but in this case, value is in the eye of the Product Owner with input from all the various stakeholders.  Maybe this sort of conversation is started from an executive, a stakeholder, the team, or even the true end user themselves.  Regardless, the backlog is that Scrum-sacred home where cool, hopefully valuable things go to wait until their story is planned into a sprint (and become part of the sprint backlog).  Even if the story never gets planned into a sprint, there is some satisfaction to the person that came up with the idea that it has been considered and is “on the backlog”.   As a ScrumMaster, I know that I feel satisfied when the Product Owner says, “Yep, I’ve got that on the  backlog already”.  If the idea is truly proven to be the next most valuable thing to work on, it should be planned into an upcoming sprint.  If not, it had it’s time on the backlog and maybe it falls off or is killed someday.  Call me sadistic, but I actually enjoy the killing of the occasional low-value backlog item.

The backlog can end a conversation just the same … “That’s not on our sprint backlog. Let’s backlog it for now.”

The backlog is a conversation end-er when something is brought up that isn’t on the current sprint backlog.  It’s amazing how much of an impediment (possible) future work can become if allowed to run wild.  In the old days of traditional waterfall project management, this was called scope creep and typically handled like a change request under whatever change management policy may have existed.  In most cases, meetings were called, the change was assessed, guess-timates were given, and friends or enemies were made as some change committee yeah-ed or nah-ed it.  All of that took time, time away from the team working on the approved scope of the project; more time in some cases than others depending on the degree of the change and the corporate bureaucracy in place.    Under Scrum, the power of the backlog makes clear what is in the current sprint backlog and what should be “backlogged” for a future sprint.  This means the team remains focused on the current sprint.

The backlog influences conversation … “We might want to add another developer to the team. I’ve got a 2 year backlog built up!”

The backlog influences conversations day in and day out throughout the life of the product.  One might even say, the backlog speaks.  The backlog says …

  • How much technical debt still exists for a product (especially if you religiously capture bugs and such in the backlog).
  • How much value remains to be implemented for the product.
  • Whether continued investment in a product or Scrum will continue for 1,2, 3 or however many months/years.
  • All that the team accomplished and the value delivered in past sprints.
  • And, so much more!

So, next time you overhear things like “it’s on the backlog”, “backlog it”, or “it’s not on our sprint backlog”, just remember that it’s all in the power of the backlog.


A Scrum Board Is Worth A Thousand Words

Last week, we had three tours in three days around here.    Yes, I said “tours”.  “A tour of what?”, you may ask.  A tour of our Agile transformation!  Now, understand you-me that tours are typically reserved for our state-of-the-art manufacturing facility (not a plug, just a reality).   At first, I didn’t realize there was much of a show to be had with all our old cubicles and dingy carpet, but apparently I was all wrong.  The tours were such a hit that we’re now making a video!  Yes, that’s right, a video… an Agile transformation video.

We gave tours to three different groups, two stakeholder groups and one VIP.  Each tour began at our local copy of The Agile Manifesto where we explained the values and principles that guide us.  Then, the tour moved into our beloved Scrum Pit (a.k.a., “The Pig Sty”) where we used the 9 Scrum Boards to visually eplain how Scrum works.  Last but not least, we walked the tour groups through the bullpen areas for 6 of our 9 Scrum teams to demonstrate the open collaboration environment we’ve established.

The mere fact that we had three tours in three days really demonstrated two things to me: 1) Our leadership is proud of what we’ve accomplished with our Agile transformation in just 8 sprints and 2) we’ve really done well by way of “visible information radiators”.  Like the old saying, “A picture is worth a thousand words”, a Scrum Board is worth a thousand  words too!  Our towering walls of magnetic whiteboards with index cards seemingly-chaotic, yet intentionally-placed  really seemed to leave quite the impression with our tour groups.  I know now that having handed them a document or an illustration or shown information buried in some tool wouldn’t have nearly the impact.  Our visible information radiators worked!  At the time of the tours, we were mid-way through the 8th sprint across 9 Scrum teams, and progress (or lack thereof) was clearly visible within a 360° view of the Scrum Pit.    I guess what I’m getting at here is simple … When your hand gets tired of writing story after story or task after task and you’ve got paper cuts on both hands, just remember that a well-constructed, well-maintained Scrum Board is the ultimate visible information radiator and worth a thousand words.


Story Points: What’s The Point?

So, what’s the point of Story Points?  9 Scrum teams and 8 sprints into our Agile transformation and it seems that some still struggle with the proper use of Story Points, a common relative estimating technique.  That said, I put together the following tips on this topic to help my teams (hopefully they will be of help to your teams as well).

  1. Story points are a relative measure of effort to done, NOT complexity, NOT priority, NOT sequence.  Something that is highly complex might take very little effort to complete and might be considered 1 or 2 or 3 story points. On the other hand, a 13 point story might be worth further decomposing into smaller, independent stories.
  2. A common technique for story points is the use of the famous Fibonacci sequence of 0 1 2 3 5 8 13, 0 being hardly any effort and 13 being the most effort.  Commit it to memory! Say it frontwards, backwards, forwards until you make it a habit.  Or, make a game of it and get some Planning Poker cards for your teams.
  3. Story points must always be established before tasks and task hours.  You can do them as part of backlog grooming, at the start of your sprint planning, or even negotiate them over e-mail, but never-ever do tasks and task hours before you establish story points.  If you do, you basically negate the benefit of your relative estimating technique.
  4. After establishing story points for stories within a given sprint, you should be able to group all the 13’s and the 8’s and the 5’s and so on and they be of relatively the same effort.  Make a point of thinking about it that way during your Sprint Planning.  Furthermore, you can use the task hours you come up with in Sprint Planning to make sure it all jives.  If you have a 13 point story and a 3 point story and both have just 6 hours of tasks then it is questionable as to whether you got the story points right or if you’ve considered all tasks.
  5. Story points are determined by the Team (based on all that has to be accomplished to meet your definition of done).  It’s not about just analysis or just QA or just coding.  The ScrumMaster and the Product Owner do not determine story points.
  6. There is indeed such thing as a zero point story if it’s something that the team has relatively no effort for.

The point of Story Points is to someday stop having to think about all those tedious task hours.  If you know your team’s velocity of story points over time, you can use story points to determine what can nicely fit within a sprint.  For instance, I know that some of my teams at full capacity are 40-ish story point teams.  With that knowledge, the Product Owner can select 40-ish points of stories for the team to work on in any given sprint.