Archive for the ‘Tools’ Category

• Upcoming Conferences

  Date: 2011.05.04 | Category: Agile, Conferences, Innovation Games, Presentations, Scrum, Tools | Response: 0

  Been really quiet these past months, but I wanted to share some upcoming places where you can see me in action.

  1. PMI San Diego Annual Conference – On May 13th, I will be giving a class on Estimating and Planning.  On May 14th, I will be giving a short tutorial on how to use Innovation Games to prioritize.
  2. San Francisco Agile Conference – my colleague and friend, Angeline Tan (@agilemeister), invited me to be a speaker at this conference she has been working very hard to organize.  On June 16th, I will be presenting Improve Flow Through Prioritization.

  You can still register for both the PMI San Diego Conference and San Francisco Agile Conference.

• Writing Good User Stories

  Date: 2011.02.07 | Category: Agile, Coaching, Communication, Extreme Programming, Lean, Planning, Tools, User Stories | Response: 1

  User stories are tool that originated from Extreme Programming and have become the de facto way Agile teams document and collect their requirements.  There is a lot written on user stories (link, link, link), so I am just going to talk about what I consider important in writing good stories since I see a LOT of really bad ones out there today.

  For those who do not know, stories are a lightweight artifact that allows us to both capture the business’s needs AND plan the work.  They are typically written on index cards (yes…little 3×5 or 4×6 cards) in the language of the business or customer.  With user stories, we only write enough to capture the user’s needs and no more.  We tend to view stories not as complete specification of the requirements, but as placeholders for later conversations between the developers and the business.

  When used properly, a user story’s lack of detail provides us a great deal of utility – we can use the same document to talk about a requirement from a high-level, zoom in on implementation details and jump back out, all in the course of a few sentences.  Then once we are done talking about requirements, we can consider risk, identify dependencies and create a project plan without ever having to put down the index card.  Wow !!  I know of no other requirements artifacts out there allows us such utility.

  Over the years people who are really successful with stories have settled on some commonalities found in all stories:

  • Role: who, or what, is going to use this feature?
  • Feature (or capability): what is the Team going to deliver, or add, after they finished their work?
  • Value: why does the business even want this feature?  What impact to the business will it have?
  • Acceptance Criteria: how will we know if this feature is done?
  • Estimate: how much does the Team think this feature will cost?

  IMO, in order for a story to be considered complete it has to have ALL the characteristics described above.  I find that when people have trouble with defining all the characteristics, the stories are not what I call ripe, i.e. they have not been thought through well enough to be usable by the Team.  In addition to these characteristics, stories also should follow the INVEST criteria (this great article by J.B. Rainsberger talks about INVEST as well).

  Mike Cohn has written a great book on user stories.  Unfortunately, for all the goodness in the book, folks seem to have focused on the one bit of junk in the book – the user story template.  In his book, Mike offers up a template some teams found helpful with writing stories and from there this template has been the source of so many bad stories that I am not going to give it anymore more ink (or bits).  What I object to about the template is that it causes people to stop thinking as they mechanically fill in role, feature and value and omit acceptance criteria and estimate (presumably because they are missing from the template).  When I see people struggle with stories, it is because they are trying to jam their business into some template that helped some unnamed team  (who probably doesn’t even use this template anymore) five or six years ago and – surprise – it doesn’t fit where they are right now.

  There is a thinking process that needs to occur before you write a single story.  The steps I tend to see people completing who are successful writing stories are listed below.  Please keep in mind, while these steps are linear in my post, one can jump back, forward and skip around as it makes sense.  The goal is to have answered these questions by the time you have finished your user story exploration.

  1. What are the roles (or users) that will use your system?
  2. What are their needs?  How does the product help them accomplish that?
  3. What features (or capabilities) do you want to provide these roles?
  4. Why are these features valuable to the business?  What sorts of business outcomes can we expect from these features?
  5. What are the priorities of these features?  Did we make a promise to deliver some already?
  6. How would you know if these features are done?

  Finally, people have a tendency to want to write a lot of details on the front of the story card.  I have two suggestions for these people.  First, use smaller cards – really.  User stories are NOT specifications or requirements documents.  They are just index cards capturing the user’s needs and reminders that we have to capture those implementation details later.  If you are trying to cram more and more onto an index card, that might be sign that you may need specs or some type of design documentation in addition to user stories.  Second, the types of details that people are trying to write down are actually acceptance criteria.  By pushing those details into the test cases, we keep the story in the language of the business and retain the focus on the feature and value your Team is providing.

• Reading a Release Burndown Chart

  Date: 2010.11.08 | Category: Agile, Communication, Planning, Product Owner, Scrum, ScrumMaster, Tools | Response: 1

  In Scrum, we use a lot of easy-to-understand tools to communicate status.  A very common tool is a burndown chart.  In this diagram, I am showing a sample Release Burndown chart for a Team with eight Sprints in their release and will talk about how this is commonly used on a Scrum Team.  At the start of the release, the Team estimated 130 units of work would be delivered in eight Sprints.  At the end of Sprint #1, they delivered twelve units of work (the green bar) and 118 units remained (the red bar).  As the release progressed, a little more of the Product Backlog was delivered by the Team in the next two Sprints.

  In Sprint #4, the scope of the release increased by thirteen units (the yellow bar) and the Team only completed three units of added functionality.  In the figure, one can see the velocity of the Team increased during Sprints #5 and #6, completing twenty and twenty-one units of work, respectively.

  At the end of Sprint #6, it was clear the scope of the release was too large for the Team to complete before the deadline.  The Team’s velocity of twenty-one units per Sprint and the concept of yesterday’s weather, indicated the Team would not burndown all the remaining work before the end of Sprint #8.  As a result of this data, twenty-five units of low business value Product Backlog items were dropped, or descoped, from the release by the Product Owner.  When Sprint #8 was completed, nine units of work remained, but it had marginal business value.

• Scrum Gathering Amsterdam – Nov 15th to Nov 17th

  Date: 2010.11.01 | Category: Conferences, Presentations, Scrum, Tools | Response: 0

  If you are looking for me in November, you can find me in Amsterdam!  I will be attending the Scrum Gathering and will be leading two really interesting sessions.

  1. Powerful Questions: picking the right question or reframing an issue can introduce a profound shift in the conversation. In this hands-on workshop, we will discuss how to create your own powerful questions and practice this skill. Leave with a practical tool you can use with your Teams today.
  2. Removing Impediments with Drawings: pictures convey ideas more clearly and have a greater impact than a simple conversation. In this hands-on workshop based on Dan Roam’s book, The Back of the Napkin, we will learn the six types of diagrams used in business and how select the right picture for your problem. Come ready to draw diagrams that will create a shift in how you visualize your impediments and help remove them from your organization.

• Using a Sprint Burndown Chart

  Date: 2010.10.30 | Category: Scrum, Tools | Response: 0

  

  A Sprint Burndown chart is a simple tool used by the Team to provide a measurement on how close they are to meeting the Sprint Goal by the end of the Sprint.  Burndown charts are common in Scrum and are simply the trend of work remaining across time in a Sprint, a release, or a product.  The source of raw data for a burndown is the Sprint Backlog, with work remaining tracked on the vertical axis and the time period (days of a Sprint) tracked on the horizontal axis.  The Sprint Backlog is just the collection of tasks which represent the Team’s current understanding of how they plan to achieve the Sprint Goal.

  Sprint Burndown charts are evolving and active artifacts on a Scrum Team.  When a Sprint Backlog item - a single task or deliverable defined and estimated by a Team member - moves from in progress to complete, it’s estimate is removed from the total estimated work remaining in the Sprint.  There is not a lot of value estimating how many hours are remaining – the work is either done or not.  However, as a Team further refines their understanding of what needs to be done, creating new Sprint Backlog and estimates are added to the total estimated work remaining.  It is important that the Sprint Backlog and Sprint Burndown chart stay in sync since the graph gives visibility on the Team’s understanding of the work.

  There are four common patterns in most Sprint Burndown charts.  The sample chart above, based on real Sprint data from a 2010 Scrum Team, displays all of these patterns.

  1. The Sprint Burndown goes flat, as seen on Days #4 and #5.
  2. The projected trend (or slope) has the Team completing the Sprint after the timebox expires, as shown between Days #6 and #7.
  3. New work is added late in the Sprint, as indicated on Day #6.
  4. A large delta between the actual progress of the Team and the predicted progress of the Team (as if they had burned down an equal amount of work each day), as seen between Days #5 to #9.

  In all these cases, these patterns provide an opportunity for the Team to discuss what is really going on and provide an explanation.  If the Team is confident they can still fulfill the Sprint Goal regardless of how the data is displayed in the Sprint Burndown chart, the Product Owner and the ScrumMaster should always respect the judgement of the Team.  Recall, the Team commits to delivering the Sprint Goal at the Sprint Review, not to deliver the Sprint Backlog items.

• New Offering – Innovation Games®

  Date: 2010.09.02 | Category: Agile, Collaboration, Design Excellence, Games, Innovation Games, Product Owner, Scrum, Tools, Voice of the Customer | Response: 1

  On May 6^th and 7^th, I attended an Innovations Games^® consultant’s class hosted by Luke Hohmann.  Innovations Games^® are collaborative games designed to help business people develop and prioritize new product ideas.  In the context of Scrum, these games are tools the Product Owner and product designers can use to engage the customers and different business stakeholders in defining the requirements for a product and thinking about product roadmap and multigenerational release plan.  Not a lot is written about the “fuzzy front-end” for Scrum teams and Innovations Games^® fill that significant gap in way that is consistent with the Scrum values and principles.

  It was quite instructive to hear about the games and how they work from Luke.  From the different case studies discussed, we really illuminated the dynamics involved with selecting the right game for problem.  In addition, a few of my misunderstandings about the purpose of the games and how they are played from reading the book were cleared up as well.  What I liked most about the class was in addition to talking about the games, we played a lot of them in the course of two days.

  1. Remember the Future (played)
  2. Prune the Product Tree (played)
  3. Speed Boat (played)
  4. Product Box (played)
  5. Buy a Feature (played)
  6. 20-20 Vision (played)
  7. Show and Tell (played)
  8. The Apprentice
  9. Start Your Day
  10. Spider Web
  11. Me and My Shadow
  12. Give Them a Hot Tub

  Below are pictures of the Product Box I created for Look Forward Consulting announcing the new service available.  I look forward to using these games more and helping Scrum teams with improving prioritization and collaboration with their customers.

  

  

• Reading List (1st Half of 2010)

  Date: 2010.08.23 | Category: Agile, Coaching, Communication, Documentation, Lean, Personal, Retrospectives, Scrum, ScrumMaster, Team, Tools, Training, Transitions | Response: 0

  Wow!  I have read a LOT in the last six months!  I guess that is one of the advantages of being on the road for about six months.

  1. Understanding A3 Thinking – excellent description of how to use and create an A3: a Lean tool for executing Plan-Do-Check-Act (the Deming cycle).  This is the definitive source on A3, Henrik Kniberg has an Agile example and template on his site.
  2. Getting the Right Things Done – good description of the concept of True North, developing strategy from True North and the respectful nature of Lean, the rest is kinda dull.
  3. Pedagogy of the Oppressed – unique perspective on the characteristics of oppression, the oppressed and the oppressors; liberation for both the oppressed and the oppressors originates when the oppressed become fully engaged in the human dialogue of being, not simply exchanging roles with the oppressors.  Interesting connections to corporate life in the 21st century.
  4. Project Retrospectives – discussion on the importance of making a deep-dive examination of a software project when it finally is complete with detailed exercises and agenda.  This is great book if you want to know more about retrospectives.
  5. More Secrets of Consulting – just brilliant!  If you liked the first book, this one has so many practical gems for the consultant.  The only tedious parts of this book are the references to his other books.  My favorite tool: the Wishing Wand.
  6. The Future of Management – this book was a favorite of the CEO at my last client.  There are many Scrum concepts in the case studies provided.  Too bad that many of the principles of self-organization and empowerment supported by the executives never filtered down to the teams
  7. Coaching Agile Teams – WOW!  This is an awesome book, deep and rich with many profound insights on the various roles of an Agile coach.  In addition, Lyssa provides practical tools to improve both the coach and the individual.  This is definitely a book to return to again and again.
  8. Training From the Back of the Room – this is my favorite book from the last six months since it has had the most impact on my personal performance.  It has changed my perspective on how to train adults with its sound theory of education and myriad of exercises which bolster learning.  Share this book with anyone who trains adults (thanks to “Agile Bob” Hartman for tweeting this book title!)
  9. Practices for Scaling Lean & Agile Development – comprehensive companion book to Scaling Lean & Agile Development (which is very good on Lean and Scrum).  This book is full of good stuff, but just too long.  Unless you are a guru (or wanna be), stick with the first book.
  10. Succeeding with Agile – Mike Cohn has put out another great book based on his years of practical experience with Scrum.  This book is also pretty long, but not tedious.  A great read if you have some experience with Scrum, but want to improve the overall experience, apply targeted improvements or figure out how to expand the reach of Scrum in your organization – it covers it all.
  11. The Back of the Napkin – provides a framework on how to apply visual thinking tools to explain and sell ideas.  Since most of the work I do is conceptual, being able to draw a powerful picture is a useful skill.  A nice addition to my consultant toolkit and I look forward to sharing it with others (I didn’t find the companion book that useful, so skip it).
  12. Hitchhiker’s Guide to the Galaxy series (not pictured) – these books were consistently entertaining, surreal and light; most were less than 200 pages.  The pace slows down around book 3 (Life, the Universe and Everything), but delightful nonetheless.  I cannot believe I just discovered them in my mid-30′s!

  Believe it or not, there are a few books I did not get a chance to read.  I guess these will have to wait until after vacation.

  • Leading Out Loud – about finding your authentic voice in business.  I bought this to get some ideas about leadership and self-organizing teams.
  • Hope is Not a Strategy – I need to understand the sales process better and improve my ability to sell.  This looked interesting.

• Best Links of the Week – New Year Edition

  Date: 2010.01.05 | Category: Agile, Links of the Week, Scrum, Team, Testing, Tools, Transitions | Response: 0

  New Year links, a little late, but ready for your review.

  1. Defense Procurement Goes Agile – a summary from the Agile Process Leadership Network’s (APLN) October 2009  meeting describing how the DoD is moving away from waterfall to an iterative, incremental processes.
  2. Mixing it up with Agile & PMI – Orange County PM, Donna Reed, makes the claim that to be a successful Agile PM one needs to “move away from ACTIVITY-BASED project management toward VALUE-BASED project management.”
  3. Starting Scrum: What Would be the Logical Position of a Classic PM – SM or PO? – a Google groups discussion posed by a member with some excellent commentary.
  4. Synchronize Rather than Overlap Sprints - Mike Cohn explains why aligning Sprint end dates within one or two days of each other is a much better way to coordinate multiple Scrum teams.
  5. Agile Antipattern: Changing the Definition of Done – Bob Hartman discusses how the pressure to meet deadlines is simply “deficit spending” on your project with a bill that will get paid off sooner than you think.
  6. Welfare CSM Day 3: Experimental Mobiles & Rainforest Birds – interesting experience report about a different type of Certified ScrumMaster trainer; be sure to read the comments for additional insights and reflections by the other participants.
  7. UI Test Automation Tools are Snake Oil – an opinionated piece from Michael Feathers on the value of that expensive UI test tool gathering dust in your organization.

• Shaking Up Those Old Bones

  Date: 2009.02.18 | Category: Extreme Programming, Scrum, Tools | Response: 0

  Jeff Patton has a good blog entry on why he is creating user story maps to maintain the Big Vision.  At the last conference in Boston, I attended his tutorial on user story maps.  Organizing the Product Backlog into a backbone of critical features, a walking skeleton of a barely releasable product and a series of releases is definitely the way to go when dealing with a large collection of user stories.  The best thing I like about the map idea is that it is visual.

• Picking The Right Tool

  Date: 2008.11.21 | Category: Agile, Coaching, Collaboration, Tools | Response: 0

  Last week, I ran a “lessons learned” exercise using the Wall of Wonder.  There were some issues around trust and safety with this group and I did not think the venue of “lessons learned” was the right forum to confront these issues.  So, when one of the participants piped in with a suggestion to do the exercise anonymously, I figured it was worth a try.

  First off, let me say there is a time and a place for anonymous feedback, especially when you think the results will be skewed one way or another on how one or two key actors will respond.  In this case, it probably would have been a good idea to do anonymous feedback, just not with the tool I selected.  The tool I selected relied on people owning their comments by reading them out loud and then answering questions posed by the group in order to provide clarification or further refinement.  Wall of Wonder is designed to generate a free flow group discussion and analysis of ideas in rapid succession.

  By running the exercise anonymously, what I ended up with were a bunch of post-it notes gathered from everyone, reading them out loud and asking people if they wanted to comment on what they thought the author intended.  It had a less than satisfactory result; people were trying to guess at the author’s intent and not revealing their own thoughts and feelings.  Well…that is not exactly true, it was just very indirect.

  So, next time you think you might want to gather anonymous data, don’t use a group exercise like Wall of Wonder.  Try things like secret balloting\anonymous dot voting on pre-selected topics or even a Triple Nickels exercise.  Just select the right tool for the job at hand.