Advertisements

Use Case Driven Scrum


In today’s software development community, Use Cases are often frowned upon.  A quick search on Google for “Use Cases Scrum” and you quickly find that they are put up against User Stories and quickly lose the fight.  I believe in Use Cases because they force stakeholders and the development team to have the right discussions in a structured way.  They also expose many things you will not think about when writing requirements in other ways.

But the art of writing Use Cases is dying.  “Uncle Bob” Martin has said that it shouldn’t take longer than 15 minutes to teach someone how to write use cases[1].  He’s wrong and unfortunately hyperbolic.  But these are the Agile times we live in, when everything invented before the Protestant-like reformation is looked upon as sacrilege.

I believe in Scrum.  I think it can wholly benefit organizations with small teams that need to be more nimble or agile.  But I don’t think Scrum is exclusive from Use Cases.  Here is the definition of a product backlog from the Bible of Scrum, The Scrum Guide:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Notice it says requirementsThe Scrum Guide does not say how to do requirements (User Stories come from XP), it just says that they need to be in the Product Backlog.

So this is where my proposal for Use Case – Driven Scrum starts.  Put your Use Cases in the Product Backlog.  Now one of the criticisms of Use Cases is that they are too much documentation and take too long to write.  Well, don’t write them out then!  Just start by identifying the Use Cases you should do (give only their title).  For example, put the Use Case “Log into system” into the backlog, but don’t bother to detail it out at first.

Scrum practitioners know that undefined product backlog items belong at the bottom and as they move up in priority, they become better groomed as the following picture illustrates.

product_backlog_horizons_details_priorities2

This leads to the second part of my proposal.  Refine the Use Cases as they move up the backlog.  Add the basic flow or maybe the primary actors.  This becomes part of your Product Backlog grooming.

Finally, most full use cases with all their basic and alternative flows will not fit into one sprint.  So the final part is to break them down into scenarios that will fit into one sprint.  Mind you that use case flows and scenarios are not the same!  The basic flow is always a scenario, but mixing in the alternative flows is where it gets interesting. J

The tactics of breaking product backlog items up really depends on the tool you use for tracking your work.  Spreadsheets, Rally, and Team Foundation Server all have different ways to do this.  I hope you’ve enjoyed this article and would love to hear your feedback below.  Good luck in your journeys of software development!

[1] http://alistair.cockburn.us/get/2231

Advertisements

What is Software Engineering in the 21st Century?


In February of 2001, 17 people met in Colorado to discuss how to move the Software Engineering discipline forward.  They were frustrated that their more lightweight, adaptive methods were not being tried while watching heavier methodologies continue to fail with over budget and over schedule projects.  They correctly surmised that a revolution would be needed to make the Software Engineering community hear and, more importantly, implement their solutions.

They could have left in disagreement and disarray over non-essential questions like: What’s better, Scrum or Feature Driven Development?  Fortunately for the Software Engineering field, they didn’t.  They wrote a Manifesto which is shown below:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Their Manifesto worked beyond their wildest dreams!  Like any revolution, there was resistance, especially in the establishment.  But after 10 years, it was clear that they had won the war.  The establishment could not resist any more and all discussions on Software Engineering now have to include Agile practices.

After the American Revolution, the American founding fathers were faced with a whole new set of problems that were in many respects bigger and more complex than winning the revolution in the first place.  The Agile Revolution finds itself today in a similar situation.  Questions such as, “What is the best way to scale Agile to an entire Enterprise?” are what need to be answered today.  The Agile movement would be wise to not throw away everything that came before it in Software Engineering, but rather mix and modify it to set our discipline on a new course.  This is what the Americans did when they took the King concept, mixed it with democracy, and came up with the modern presidency.  I’m looking forward to the next 10 years to see where this mixture leads us!

CMMI version 1.3 and Agile


Well, the Software Engineering Institute (SEI) just published the newest version of the venerated CMMI and there are many side notes in the CMMI-DEV version that touch on using an Agile methodology with CMMI.  I’ve always thought this was possible and I’m glad to see the SEI has taken the lead.

For example, here is the “Agile note” in the configuration management section:

In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done.

I especially like this one from the Requirements Development section:

In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. (See ―Interpreting CMMI When Using Agile Approaches‖ in Part I.)

Download the latest CMMI-DEV and enjoy!

TFS Agile 5.0 Planning Worksheets


Want to get the planning worksheets outside of TFS?  Here they are:

Product Planning

Iteration Backlog

Follow these instructions from Aaron Bjork to use:

Product Planning Workbook

To bind the Product Planning workbook to your team project follow these steps:

  • Open the Product Planning workbook.
  • Place your cursor in cell A1 of the Product Backlog worksheet.
  • Switch to the Team ribbon and click New List.
  • Select your Team Project and click Connect.
  • From the New List dialog, select the Product Planning work item query.

Your Product Planning workbook is now connected to your team project and ready to use.

Iteration Backlog Workbook

To bind the Iteration Backlog workbook to your team project follow these steps:

  • Place your cursor in cell A1 of the Iteration Backlog worksheet.
  • Switch to the Team ribbon and click New List.
  • Select your Team Project and click Connect.
  • From the New List dialog, select one of the Iteration Backlog queries.  The query you select must be a Tree query and must contain a parent/child relationship between User Stories and Tasks.

image

  • Save the workbook locally.
  • Close the workbook and re-open it.
  • After re-opening, the workbook will attach itself to your Analysis Services server and set values for a series of document properties use by the burndown worksheet.
  • Save the workbook again.

Your Iteration Backlog workbook is now connected to your team project and ready to use.

 

MSF for Agile Software Development 5 – Process Guidance in Word format


If you’re like me, you like to print things out and sit down with them to really absorb and understand them.  Couldn’t find any way to nicely print out the MSF Process Guidance for Agile in the new Visual Studio 2010 Team Foundation Server, so I made my own!

Enjoy!

MSF for Agile Software Development v5 – Process Guidance