Archive for the ‘Extreme Programming’ 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.

• Scrum Bill of Rights

  Date: 2011.01.24 | Category: Extreme Programming, Product Owner, Scrum, ScrumMaster, Team | Response: 1

  One of the things I admired about Extreme Programming (XP) was the simplicity of the roles defined in the Green Book.  In XP, there are only two roles: Customer and Programmer.  When you are using XP, the Customer makes business decisions, Programmers make technical decisions and one role may not substitute their judgement for the other.  In short, Programmers do not make business decisions and Customers do not make technical decisions.  Kent Beck and Martin Fowler even went so far to add a Bill of Rights, which clarifies what people can expect for one another.

  Scrum does not have anything similar, so I decided to create my own (modeled on the XP rights).  Feel free to distribute and share.

  Every Team member has the following rights:

  • To produce quality work at all times.
  • To know what is needed from the business with clear declarations of priority.
  • To ask for, and receive, help from peers, management, and customers.
  • To experiment with new ideas, technologies and roles to grow both as a professional and an individual.

  Every Product Owner has the following rights:

  • To receive the greatest possible value out of every week.
  • To know what can be accomplished by the Team, when and at what cost.
  • To see incremental progress in a viable product proven to work by passing acceptance criteria they specify.
  • To be informed of schedule changes promptly in order to take effective countermeasures and reset expectations with the stakeholders.
  • To collaborate with the business on setting the future direction of the product.

  Every ScrumMaster has the following rights:

  • To try out different ideas, approaches and techniques to remove impediments which impede the flow of value.
  • To be given time for initiatives to take hold and produce change.
  • To take measured risks and learn from setbacks.
  • To be supported by senior leaders in the organization.
  • To be provided access to different parts of the business while identifying and removing impediments.

  Every Stakeholder has the following rights:

  • To receive regular status updates through interacting with a working product.
  • To change their mind, substitute functionality, and adjust priorities without paying exorbitant costs.
  • To cancel the product at any time and be left with a working product providing real business value reflecting the investment to date.

• 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 – August 13th 2010

  Date: 2010.08.13 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Pair Programming, PMI, Scrum, Transitions | Response: 0

  Beat the summer heat with these engaging posts.

  1. Lean Software Experience Report – detailed discussion of how XP and Lean were combined for GlaxoSmithKlein IT projects to support new drug development.
  2. Making People Before Making Products – great article highlighting the import role management plays in developing & mentoring knowledgable workers; watch out for the funky scrollbar.
  3. How to Succeed With Scrum When Your Company is Anti-Agile? - Rob Diana talks about how to recover from previous failed Agile attempts in your company with time-honored values such as lies and entrapment.
  4. How to Do Agile When We Only Have 50 Crap Developers? – a short rant on the importance of having good people on your Agile team; the comments are very interesting, too.
  5. Pair Programming Interviews – an experience report from Rob Bowley on how to use pair programming in your interview process.
  6. The Secret Sauce Recipe to Agile Coaching – Rob Myers talks about what it takes to become an excellent coach for an Agile team.
  7. A Coaching Toolkit – a collection of principles to keep in mind when coaching Agile teams.
  8. Scrum Adoption #1: Awakening – Tobias Mayer examines the concept of awakening as a prerequisite for making inroads with Scrum in your company.
  9. How to Screw Up Agile – great mind map on the factors which inhibit (and help) Agile grow in your organization.

• Best Links of the Week – July 30th 2010

  Date: 2010.07.30 | Category: Agile, Certified ScrumMaster, Extreme Programming, Lean, Links of the Week, Open Workspace, Pair Programming, PMI, Scrum, Task Board, Team | Response: 0

  More great writings gathered from far and wide.

  1. Scrum at Mind Candy – brief video of a task board in action over a three month period.
  2. Confessions of an Agile Project Manager – PMI sponsored a video contest among PMP using Agile – check out the results on YouTube!
  3. Thoughts on two months pairing - Sarah Mei reflects on her experience pair programming and the benefits it has provided her professional & personal life.
  4. Can Agile Learn Anything from PMBOK? - Dennis Stevens looks at how the PMBOK supports, compliments and impedes Agile and proposes some solutions to make the two synchronize better.
  5. Multitasking Gets You There Later - Roger Brown discusses a common paradigm in project management when dealing with too many projects and too few people.
  6. Waterfall, Lean\Kanban and Scrum – Ken Schwaber, co-creator of Scrum, discusses why Scrum relies on empirical process control theory and why they did not choose Lean or a defined process.
  7. The Role of Middle Management in Toyota or a Lean System – special post on the new focus of management in Agile organizations.
  8. Team Room – want to get increased focus, quality and retention from your Team?  Check out this team room article by Martin Fowler.
  9. Agile + UX: six strategies for more agile user experience – how Comcast is combining good user experience (UX) practices with Scrum.
  10. June 2010 CSM class – very cool visualization of a Certified ScrumMaster class taught by Tobias Mayer and Bachan Anand.

• How I Became a Certified ScrumMaster

  Date: 2010.07.15 | Category: Extreme Programming, Personal, Scrum, ScrumMaster | Response: 0

  Just wanted to share a bit of my personal Scrum journey for those who might be interested and why I find Scrum to be very compelling.

  I became a CSM during 2005 after attending an early CSM course provided by Ken Schwaber, Paul Hodgetts and Tobias Mayer.  Before that experience, I had been using Extreme Programming (XP) to write and deliver software for three years.  Ken’s CSM class helped me understand that while interesting, XP is mostly an internal conversation among developers about how to build great software.  Scrum, on the other hand, is about creating cross-functional, collaborative Teams to deliver astonishing results to the business.  What most impressed me about Ken’s description of Scrum was the importance of providing transparency and the role Scrum can play in raising the professionalism of our community.  It was with that vision that I became more interested in how I could practice Scrum and I was on the lookout for experiences that would allow me to see Scrum in action.

• 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 22nd 2010

  Date: 2010.02.22 | Category: Agile, Collaboration, Continuous Integration, Pair Programming, Refactoring, Scrum, Test-Driven Development | Response: 0

  Links to share with your friends and co-workers

  1. Is an Agile PMO possible? – Curt Finch talks about the values of both Agile practices, PMI standards and how to marry the two.
  2. Self-organization: the secret sauce for improving your Scrum team – In this 90-miute video for Google, Jeff Sutherland talks about the role of self-organization and other advanced Scrum techniques.
  3. The Agile Flywheel – a short experience report describing how one company melded Scrum with their mature ITIL processes.
  4. Just do it: a quick intro to Agile’s technical practices – a summary of the technical core of Agile software development by Abby Fichtner.
  5. I love pair programming – Discussion on the effectiveness and the challenges of pair programming after a five month trial.

• 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 – Feb 1st 2010

  Date: 2010.02.01 | Category: Agile, Communication, Extreme Programming, PMI, Product Owner, Scrum, ScrumMaster | Response: 0

  Here are two weeks worth of linkie goodness for everyone.

  1. 4th Annual State of Agile Survey - VersionOne, an Agile project management tool, has published their annual survey on the adoption of Agile; a great source of industry statistics and window into how other companies are using Agile.
  2. From Waterfall to Agile – in this 16-minute video Ian Culling, the CTO of VersionOne, talks about the Agile journey and common pitfalls he has observed.
  3. Scrum for Managers – in this 90-minute talk Mitch Lacey, CST and (former) Microsoft PMP, gives an excellent overview of Scrum and the new role for managers.
  4. Protect People - Jurgen Appelo discusses the role of managers in creating a safe interpersonal environment so self-organizing teams can form and flourish.
  5. Tips for First-Time Scrummasters – pitfalls to look out for on that first Scrum project.
  6. Top 10 Estimation Practices in Agile – excellent, excellent summary of current practice on Agile teams today.
  7. Assessing Agile Readiness – a 20-minute video from Joshua Kerievsky discussing the process of kicking off Agile at your company.
  8. Getting Better Agile Transitions - Mike Sutton describes some factors to consider when selecting a coach to help your company become more Agile.
  9. 10 Rules for Better Management – a short checklist on ways to become a better manager; I like to item on control charts.