Skip to main content


#12 of 100 Agile Transition Guide Delights

"That went very well."  Said in reference to today's sprint planning session, and an inferred commentary upon the previous planning session which was a tornado disaster zone of a trailer park.

Few people like to attend a disaster waiting to happen.  But I've found that there are times when it's the best thing that can happen for a team.  And while I don't cheer for the tornado, I don't mind its visit to the sprint planning meeting once in a while.

I'm typically heard explaining why the tornado hit our little trailer park... it's because we didn't do any (or enough) backlog refinement.  And then people want to know what backlog refinement is - what should happen in these "meetings"?

If you search the old books and articles on Scrum you might not find this meeting mentioned.  But that's just because refining the backlog was something that most teams understood needed to happen and did what needed to be done.  Somewhere along the pa…
Recent posts

#11 of 100 Agile Transition Guide Delights

There are many ways to decompose a large task into smaller portions.  When agilist start doing this there are a few general ways to do such a thing.  Let's start by distinguishing between a story split and a story slice.

Splitting != Slicing

If you've spent some time with an ax and a pile of wood then you understand that many logs have a naturally easier way to split along with the grain direction.  It requires much less energy to split a log than it does to slice the log.

If you've spent some time baking cakes you know that people like to slice cake.  You never hear of a person wanting a split of the cake.  Many cakes have multiple layers, sometimes with different flavors in each layer.

What does this have to do with software development stories?  Well many software systems have layers, and it turns out that it is easy to split the layers apart.  For example: the UI layer is easy to separate from the Persistence layer.  Many organizations separate their teams along these bou…

#10 of 100 Agile Transition Guide Delights

I am working with a team that is in transition.  They have been told that they will practice Scrum.  I don't bother to question this directive from above.  I figure that the people above the team don't know why either...  oh, yes they were at the company all-hands meeting where IT was handed down, there were the typical platitude reasons for the change, faster time to market, being able to respond to new influences in the greater marketplace (e.g. AI, Serverless Environments, etc.) all sounded great at the town hall.  But when asked why this particular team that will never see those technologies in their arena would need to practice Scrum - the best reason is - because we said so.  So that is the CHANGE - it has been forced upon these 7 people.  I am acting upon the transition they are going through.  The current transition is in writing stories.  All have said they are use to working with stories, so we dive right in... but they are not very good - it is almost like English i…

#9 of 100 Agile Transition Guide Delights

Have you had that conversation with the struggling team that wants to switch to Kanban?  They don't really know why - but they've heard that Kanban will be easier.  So why don't they switch processes?

We are failing at Scrum, so let's switch to Kanban!

Does that sentence make sense in your world?  I hear it quite a lot.  Well not stated that emphatically.  In fact, most teams don't know that they are failing at Scrum - but they are... it is such an easy process to follow - how could you fail?

Cutting to the gist of the problem - a team that cannot complete stories in a sprint.... well they are failing.  You could ask why they cannot complete stories in the sprint.  There may be several legitimate reasons, typically it is an impediment beyond their control.  Something like getting "sign-off" from some stakeholders that the feature desired works as expected and doesn't break anything else.  When you see this "reason" and investigate it - you wi…

#8 of 100 Agile Transition Guide Delights

I've seen way too many teams working with just a big list of stories (they call it a backlog - but it's not).  Many of these organizations can find someone to play the role of the (proxy) Product Owner, and that unlucky bloke will do the best they can at prioritizing the list... but it's still not a Product Backlog.

What is really amazing is when you hand that unlucky PO a list of SIZED stories and they can see the cost of those wee little things that seemed like a big deal because we've all been living with that crap since forever.  But now with the addition of a story size, those little nuisances become a top priority.  The team's value goes up in the eyes of the stakeholders and users because the apps are visibly being improved.

"But sizing all those stories will take forever and a day."

That is what my product owner said a few years ago at a client known for its storage products.  And being great organizers of storage, they put those skills to the list…

#7 of 100 Agile Transition Guide Delights

The product owner calls everyone together and explains the "crazy" direction we are headed and why.

Team morale does an immediate 180-degree turnaround and sky-rockets.

Product Owner has a Sprint Goal

This little tidbit of Sprint Planning often goes unnoticed, is frequently forgotten or never mentioned. But when you see the difference it makes for a bunch of devs that thought we were building the wrong thing and then realize how crafty your product owner is... well you will not forget to insist on the reasons - the goal of sprints you and the team are running.

Years ago, in a rainy distant land far from sunny Texas, I worked for a SpeakEasy. The company was a hot-shot in ISD land (Internet Service Delivery in the days of modems). They had this crazy idea to build a Voice-Over-IP telephone product and hired out the tree-hugging hippies from a little consultancy company across the lake. These hippies said they had a new collaborative way to build products that worked so much …

#6 of 100 Agile Transition Guide Delights

Sarah asked the team during Stand-up if she could pull in the other slice of the sorting widget she had been working upon.

The team looked at their board - everyone agreed they would have all the stories done by the end of the sprint and no one needed Sarah's help so that would be a good plan of action.

Working toward TINY is the key to increasing Velocity

How do you increase your Velocity?  It's not by planning to do more work!  It is by finishing more work - FIRST!

I delight in a team that proves their capability before they plan upon that capability.

Let the action preceded the planning, such that we are planning upon a strong knowledge of success.

When beginning teams wish to become high performing many mistakenly feel that getting work started earlier is the secret - it is actually the opposite of starting more work.  There is a lot of learning involved in finishing work.  This is where the high-performing team differentiates itself from other teams.  High-performing teams…