Archive for the ‘Planning’ Category

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

• Estimating & Planning for Agile Teams – Oct 2nd

  Date: 2010.09.12 | Category: Agile, Estimating & Planning, Extreme Programming, Planning, PMI, Scrum, Training | Response: 0

  Having trouble communicating deadlines to stakeholders?  Unable to get a commitment from the Team on when work will actually be delivered?  Having trouble managing dependencies?  Agile processes, like Scrum and Extreme Programming, rely on lightweight techniques to progressive guide and steer a project to completion.  In this hands-on workshop, Carlton Nettleton will review the common Agile tools used by successful Teams to produce project plans which have clear milestones and deliverables and raises risks and dependencies early.  The topics covered in this class will include:

  • Importance of creating a Definition of Done for the Team
  • The role of user stories to capture, develop and validate requirements.
  • Common estimating techniques employed by Teams.
  • How to develop and maintain a Release Plan to track progress.
  • How to use easy-to-understand Agile metrics to monitor status.
  • Link common Agile planning practices to the PMBOK.

  Participants that are PMP will earn 4 PDU.  Register today!

• Best Links of the Week – Mar 27th 2010

  Date: 2010.04.27 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Planning, PMI, Quality, Refactoring, Testing | Response: 1

  More good links to share with others.

  1. Ouija Board Estimation\Seance Sizing – a new method for estimation that relies on team, not the undead.
  2. Is the Agile Community Being Unreasonable? – InfoQ takes a look at the friction between the PMBOK and Agile principles.
  3. Toyotas’ Journey from Waterfall to Lean Software Development – Henrick Kniberg takes a visit to Toyota and peaks under the hood to see how a Lean company develops software.  What he finds will surprise you!
  4. Defining the Last Responsible Moment - Karl Scotland puts some meat on this fuzzy Lean concept by looking at the cost vs benefit of delay.
  5. Managing vs. Coaching vs. Mentoring - Jurgen Appelo makes the distinction between these three concepts.
  6. The Problems With Acceptance Testing – thoughtful entry by Jim Shore reevaluating the importance of automated acceptance testing on Agile projects.
  7. Alternatives to Acceptance Testing – more from Jim Shore on what can be used in place of automated acceptance testing.
  8. More on Automated Acceptance Testing - George Dinwiddie adds his perspective to the topic of automated acceptance testing.
  9. The Path to Frequent Deployments – a report from Kent Beck, author of Extreme Programming, on how to  increase development speed by moving from annual to quarterly to monthly to weekly and finally to daily deployments.
  10. How to Be a Great Tech Leader – Richard Kasperowski talks about the technical elements needed to succeed when running an Agile project.

• Best Links of the Week – Feb 9th 2010

  Date: 2010.02.09 | Category: Agile, Communication, Planning, PMI, Scrum, ScrumMaster, Team, Test-Driven Development, Transitions | Response: 0

  Excellent links for everyone to share.

  1. Pollyanna Pixton on Agile Leadership – a 30-minute video talking about the factors corporate leaders can influence which support Agile teams.
  2. How I Learned to Program Manage an Agile Team After 6 Years of Waterfall – Sara Ford describes in brutal candor her experience becoming an Agile PM while working on CodePlex at Microsoft.
  3. Explaining Agile – Mike Cottmeyer neatly summarizes his understanding of Agile.
  4. How to Compare Elephant Herds - Dave Nicolette finally (?) explains why comparing teams through velocity is meaningless.
  5. What Does a ScrumMaster Do? – for those of  you who are curious and wanted to know.
  6. Replacing the Iron Triangle of Project Management? – short discussion on reevaluating a well-accepted PM paradigm.
  7. Adopting Agile Development – the Role of the CIO – how senior leaders in your organization can help promote Agile adoption.
  8. Moving Beyond Scrum – a look at some reasons why one might want to take the next step.
  9. Tragic Mistakes When Adopting Test-Driven Development (TDD) - Scott Ambler discussing some pitfalls & obstacles companies encounter when they begin the process of using TDD.
  10. Comparison of Open Agile with Scrum – introduction of a domain-independent framework for delivering value while using Agile principles via a compare-and-contrast with Scrum

• Best Links of the Week – Jan 19 2010

  Date: 2010.01.19 | Category: Agile, Pair Programming, Planning, PMI, Product Owner, Scrum, Transitions | Response: 0

  Continuing with links to the best of the blogs since last week.

  1. Three things I wish I knew before jumping – PMP and Certified ScrumMaster, Pat Guariglia, shares some lessons learned after his first Scrum pilot project in 2007.
  2. Mike Cottmeyer on the Agile PMP – InfoQ has a 78-minute video from Mike Cottmeyer’s Agile 2009 talk on how Agile’s approach to managing cost and time reduces project risk rather than the traditional approach of managing scope.
  3. Determining how Agile you are comparatively – discussion on the Comparative Agility assessment for teams looking to understand how Agile they are doing in seven areas: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation.
  4. Demystifying the Product Owner role – Roman Pichler provides some truth about the Product Owner role and clears away some myths.
  5. Self-discipline & self-organization – Cutter Consortium Fellow, Jim Highsmith, emphasizes the need for discipline and excellence on Agile teams.
  6. Eight reasons why the estimates are low – some common reasons why software estimates are often too small.
  7. How pair programming really works – the IEEE publishes an article sharing four mechanisms that can improve pair programming.

• Speaking @ Fullerton Code Camp – Jan 30 & 31

  Date: 2010.01.04 | Category: Agile, Coaching, Conferences, Extreme Programming, Planning, Presentations, Scrum | Response: 0

  If you are looking to see me speak in person, be sure to come to the Fullerton Code Camp.  I will have three presentations on Agile.

  1. Experiencing Agile Through Games: Are you bored at work? Is your Agile team devoid of fun? It could be that you are following the mechanics of your process, but missed out on the critical insight, the “ah-ha” moment, where everything clicked and it all fit into place. Come to this session hosted by Carlton Nettleton and he will demonstrate as many Agile principles and practices he can in 75 minutes through a variety of short simulations and games. Walk away energized and excited about working on an Agile team.
  2. Agile Planning Workshop: Every time I speak about Agile software development, I often hear this statement, “Agile teams never know when they are going to be done.”  With the teams I coach, this is not the case.  Come to this workshop and we will walk through the steps I use when planning an Agile team.  Learn the practical tools and techniques for estimating, planning, reporting progress and keeping the stakeholders in the loop. This session will focus more on principles and tools used in Agile planning.
  3. Debunking Myths About Agile Software Development: With so many myths surrounding Scrum, Extreme Programming, Lean and Agile software development these days how is someone supposed to succeed with these processes when there is so much half-truth and opinions masquerading as practice and fact? In this workshop, we will look at the myths surrounding planning, deadlines, documentation, architecture & design, requirements, testing, pair programming and other common misconceptions about Agile teams. By the end of this session, Carlton Nettleton will provide real facts about Agile software development, refuting many of these myths once-and-for-all.

• Agile 2009: Advances in Release Planning

  Date: 2009.08.24 | Category: Agile, Conferences, Planning | Response: 0

  Stopped by to see Jim Highsmith’s session to pick up a few good ideas.  Not surprisingly, there was a good deal of focus on release planning, some focus on value and discussing features along a continuum.  In many traditionally managed products, there is an emphasis on the up-front planning, or as he termed it “wish-based planning”.  During this inception stage, management spends a lot of time trying to answer the following questions with a high degree of precision:

  1. What are the main dependencies in this product?
  2. What sort of risks do we expect?  How do we mitigate them?
  3. Do we have enough resources?  How will they be distributed?
  4. What sort of value will this product provide?
  5. How much will it cost us?
  6. When will the product be delivered?

  Of course, Agile products want to answer these questions as well and we often figure this out during release planning.  We want to know early on if the product is feasible and does it align with out goals and strategic objectives.  Where Agile teams differ is we recognize the release plan is only a guide and is flexible.  Another key difference is that an Agile team will estimate on the user story level, not at the task level.  We perform the task estimation Just-In-Time.  The creation of the release plan is really a conversation meant to answer all these questions.  Finally, while most products benefit from a release plan, there are cases of highly experimental work where an iteration-by-iteration approach is valuable.

  Another useful concept discussed at the session was the continuum of completeness for features.  Instead of assuming all features have the same level of completeness, have conversations about what needs to be delivered using this model:

      simplest -> basic -> nominal -> extensive

  With this framework in mind, we now can have discussion around trade-offs and partial delivery.  Why develop an extensive solution when the market leaders are only providing nominal?  Is that are market differentiator or just engineering gold-plating?  Or maybe we can only afford a basic implementation?  At least we can make these decisions at the product level instead of the engineers making these decisions for us.

  Finally, Jim made a big point about understanding the value for a feature.  From his experience, even a fuzzy number around the value for a feature is acceptable if detailed data is unavailable..  In his words:

  “If the product group does not have the time to calculate the value, then the programmers do not have time to estimate the cost.”

• Planning Poker

  Date: 2009.08.18 | Category: Agile, Coaching, Planning | Response: 0

  Yesterday, I had lunch with an former co-worker and she could not remember the estimating technique I showed her group last year.  I promised her I would add a link to Planning Poker on my website so she could find in the future.

  Mike Cohn first wrote about Planning Poker in his book, Agile Estimating & Planning (a VERY good book everybody who is doing anything Agile should read).  Mike’s great insight was to take a well-tested, accurate estimating technique and make it into a game.

• Focus on Adding Value, Not Features

  Date: 2009.06.18 | Category: Agile, Planning, Product Owner, Scrum | Response: 0

  I had an interesting conversation today with one of the software testers in China who was having difficulty understanding some planning concepts in Scrum.  She wanted to know if a Scrum team finished all their work early in a Sprint, would it be OK for the Team to take some planned work for the next Sprint into the current.  My first response was, “No, that work is already planned for, so the Team takes in a new piece of work that can be completed by the end of the Sprint.”  She was having a hard time wrapping her head around the concept until we got to the whiteboard and sketched out what I was thinking.  Since it was such a great conversation, I wanted to capture the explanation for others.

  Suppose you have a Scrum team and they have constructed the following release plan of their user stories.  Each user story has a value (indicated by the $ sign) and a relative size to the others.  The total value provided by this Team over the 3 Sprint release is $20.

  This is committed work that the Product Owner can take to the stakeholders with reasonable certainty it will be completed when the release date arrives in 6 weeks.  When I say reasonable certainty, I mean something along the lines of 85% confidence level.  We are very confident all the stuff in the 1st Sprint will be done, less so about some of the low value things in the 3rd Sprint.

  Keep in mind when you create an Agile release plan, you are working with incomplete information.  We spend just enough time with the user stories to understand the high level scope, high level implementation details and we provide a high level estimate.  Since we do not spend a lot of time with the details, our initial estimates for the release plan may be too high or too low.  We accept this inaccuracy because it allows us opportunities to provide greater value to the stakeholders and customers.

  In practice, this does not present too many problems because there are three forces at work on Scrum teams to ensure the stakeholders get the value they expect (and often times more).

  1. On Agile teams, the stakeholders are entitled to the most value from each programming week.  If the Team has extra capacity, they take on extra work.
  2. At the beginning of each Sprint, we ask the Team to re-estimate the user stories based on their knowledge of the app, individual skill sets, ability to work as a team and recent experience working with the app.  Normally, an implementation detail passed over at release planning with surface during Sprint Planning and that will either make the story real easy or expand the scope.  Either way, we have the Product Owner on hand to make adjustments.
  3. We focus on delivering complete chunks of value, as opposed to coding the most features possible.  In Scrum one does not allow unfinished work to cross from one Sprint to the next nor do we allow Scrum teams to start work that cannot be completed by the end of the Sprint.  No unfinished work may cross the Sprint boundary.

  Back to the original question – if a Scrum team is done early, can they pull stories planned for later Sprints?  If the story can be completed within the confines of the timebox, then absolutely yes!  Go for it!  However, the good Product Owners I have had the opportunity to work with are always looking to add more value to the release, not get things done early.  In many large organizations, you don’t get gold stars for getting done early, but you do get praise for getting more done than what was expected, i.e. improving productivity.

  What if you were a Product Owner and you could deliver this release plan?  In this release plan, the Product Owner has provided $24 of value, as opposed to the original $20 the stakeholders were expecting.

  

  How did the Product Owner do this?  Some user stories (blue boxes) were originally estimated to be large, but when implemented, were completed faster than anticipated.  There could be a variety of reasons why that is the case (which could be examined in a Retrospective), but the end result is the Team had extra capacity and Product Owner filled the gap with a new user story (green boxes) that could fit within the Sprint.  In my experience, these new user stories tend to be extremely valuable to the stakeholders and customers.  These are the user stories that just did not make it into the release and their inclusion now are special bonuses.  You make people happy with these stories.

  But why not pull stories earlier?  Can’t you just add all these bonus stories in the last Sprint?  You could and it is does not provide any extra value to pull work scheduled for Sprint 3 into Sprint 2.  Right now we have a gap in Sprint 2 looking for value.  If we pull an item from Sprint 3 we do not add to the total value provided by this Team for the release, we just conserve the amount of value the Team provides.