Agile Complexification Inverter

 Many new leaders of scrum teams want to know what the burndown chart "should" look like.  Some even start running statistical calculations on the data (I once worked with a 'coach' that had a spreadsheet custom designed to extract just such anomalies).  The best answer I've given is a session on the whiteboard to explain: how the data is obtained how accurate & precise the data is - just good enough & not any better interruptions that MAY be made ... but only by the TEAM  So here is that whiteboard session - on index cards... Let's go one at a time. They are learning to make their work visible... praise this effort - it can be quite scary to show your work. Do not use tools that show this mathematically perfect line from start to finish.  Only robots are capable of such precession, and only with the perfect PLAN. If you see something like this in the first 3 or 4 sprints... it is a good sign.  Now reduce the scope of work by at least HALF. This is ...

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

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 success...