Agile Complexification Inverter

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

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

Here's a overview of a Scrum Immersion workshop done at GameStop this month. A case study example. Normally these workshops start with the leadership (the stakeholders or shareholders) which have a vision for a product (or project). This time we skipped this activity. The purpose of the Workshop is to ensure alignment between the leadership team and the Agile Coaches with regards to the upcoming scrum workshop for the team(s). Set expectations for a transition from current (ad-hoc) practices to Scrum. Explain and educate on the role of the Product Owner. Expected Outcomes: Create a transition plan/schedule Set realistic expectations for transition and next release Overview of Scrum & leadership in an Agile environment Identify a Scrum Product Owner – review role expectations Alignment on Project/Program purpose or vision Release goal (within context of Project/Program & Scrum transition) Once we have alignment on the Product Owner role and the Project V...

Your Wish List is not a Scrum Backlog. I've seen lots of list that are referred to as a backlog.  List on paper, in spreadsheets, in powerpoint, on whiteboards, wrapped in a rubber band on index cards - they can take many forms - yet the form is not what makes a wish list into a backlog.  So what are the necessary and sufficient attributes of a backlog? A list becomes a backlog when: the items are sized (estimated) by the Development Team that will implement the item the items are ordered (prioritized) by the Product Owner by delivery order the items are visible (instantly) to the team and the stakeholders in this ordered list the stories in the list are understood to the team (well enough for sizing) items that reference additional information or requirements are easily obtained (wireframes/mock ups/technical specification/etc. via a well known location) This list of elements of an effective backlog follows from the principle of transparency -- the team shoul...

I'm working with a large client that has adopted the classic user story format for the backlog. "As a user , I want some feature  so that I receive this benefit ." Yet, I'm sure that it is not delivering the desired shared understanding that throwing out the classic business requirements document and adopting the scrum/XP user story practice is designed to deliver. So if your groups user stories have become just a piece of boiler plate language to satisfy some agile coach's requirement - maybe you should reflect upon the desired reason for user stories rather than requirements documentation so many years ago.  User stories do work.  But you have to tell a story.  Few authors are good enough to tell a story in one sentence. @davidakoontz @dayleyagile Card, Conversation, Confirmation. Card contents irrelevant. http://t.co/IIUdJJmxA1 — Ron Jeffries (@RonJeffries) May 15, 2014 Here Ron is pointing to one of the XP practices that were very successful in...

One of the suggested improvements for our AgileFest! 2013 was a  "How-To" document for planning a conference.  So in the nature of an experiment in gathering some "validated learning" I'm going to post a rough draft of this future book here.  If it gets some interest, hits, comments, suggestions then I'll turn it into an eBook. Since this page will be an on going effort to create a draft, outline, sketch, etc. of the whole how-to guide, you may want to revisit this page in a week, and again in a month. First, creating a conference is an Agile project, so treat it like any other agile project.  Hold several visioning meetings and workshops.  Insure that you and the core group explore your vision of the conference, understand the explicit goals, and try to uncover the hidden agenda of the conference drivers.  Don't kid yourselves there are alterative motives - everyone has some, so get them out in the open. Define what a suc...