Agile Complexification Inverter

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 t

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 work

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-perf

After several sprints of FAILURE, the team decides to cut in half the stories it takes into the sprint. I have worked with enough teams that are beginning with Scrum to estimate their beginning velocity fairly accurately.  Most believe I am full of IT when I suggest this.  So instead of taking my advice, they plan to fail. Start with Velocity/2 RECURSIVELY How would you define success and failure at the sprint level for a brand new (to Scrum) team/group.  I try to make it very simple - we are successful if we achieve the sprint goal.  Typically with new teams, the only goal is to accomplish the stories we've put into the sprint.  So it's easy to define success - 6 stories put into the sprint, 6 stories done at the end of the sprint, and we have a success! Invariably the team does NOT finish all 6 stories and so the result is NOT success or failure.  That's so simple.  Now if we keep track of this for a few sprints, and the product owner starts to care about team su

A manager responsible for the delivery of Project X asks the team that will do the work to estimate a first release date.  That is defined as the next sprint goal.  The team plans to meet in the large conference room to estimate the backlog and create the first iteration of a release plan. Within the first interaction with a client, the manager tells me she would be happy if we could just get the team to deliver upon the milestones and release dates.  After inquiring as to who sets those milestones she stated that some times the company imposed dates, but that usually the team was asked to estimate when the project would be complete.  That it was only after missing several deadlines that the company executives would start imposing drop-dead dates.  This sounds like a client I can delight. 1st Objective: Predictable Team After training and workshops to teach a team many managers have goals or key performance metrics they wish to achieve.  I rather don't care much about their s

A new team member drew an "ideal" straight line from the top left of the burndown chart to the end of the sprint on the bottom-right origin-line.  Another team member asked why that straight line was IDEAL? What's the "Ideal" burndown? Just because some "agile" tool they have used in the past drew that "ideal" line, they thought that it helped the team to know if they were performing on target for the sprint.  I was delighted that Julien questioned the meaning of the "ideal" line.  I've never drawn such a lie upon my hand-drawn burndown charts and may have mentioned this anomaly (or ranted about its absurdity in a training workshop). Julien explained that our team was willing to take work into the sprint that was some-what undefined, that we were accustomed to learning about the solution as we discovered the problem.  And hence we often saw the task burndown rise before it curved down and we completed sprints.  Julien thou

A package just arrived, express mail from a toy store.  I tear it open and inside are 40 PEZ dispensers and candy.  They are gifts for the teams.  Tomorrow will be a delightful day. PEZ in place of Task Hours When the team acknowledged that the task estimates would never accumulate to the number of work hours in the week - we had a great discussion.  The team of 5 people worked the typical 40 to 45 hour workweek.  Yes, we had lots of overhead chores that took us away from actual productive work on story tasks each week.  As well as those pesky Scrum meetings like planning, review & retrospective.  Heck - just doing the company's time accounting BS each week took an hour.  Yet, it wasn't like we only worked 3 to 5 hours per day.  Maybe we would be much more effective if we worked half days. Is it our inability to estimate accurately? Our over-optimistic nature? The fact that many of our tools required too much time to navigate and we spent too much time working for the

I delight in the realization a new team member has when task estimates do not equate to actual clock hours. Task Estimates != Sprint Time Task Hours vs Day of Sprint - Burndown Chart In the activity of updating the sprint burndown chart, a team-mate notes that the sprint contains 3 to 5 times the amount of work hours as our accumulated task estimates. Wonder where all that extra time is spent?  This epiphany occurs because I require the team to calculate and hand draw the team's sprint burndown chart. Immediately after stand-up someone (an unassigned, expectation upon the team) does the task of updating the chart.  They calculate the task effort remaining for all unfinished stories and update the burndown chart.  I am delighted when she notes that the sprint has 2 weeks for 5 people, meaning 2 X 40 hours X 5 people = 400 effort hours per sprint.  Yet we are only estimating and accomplishing something like 130 - 200 effort hours over the last several successful sprints.