Write a Great User Story

This is a great post from the folks at RallyDev!

What is a user story?

A user story represents a small piece of business value that a team can deliver in an iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:

  • The brief description of the need
  • The conversations that happen during backlog grooming and iteration planning to solidify the details
  • The tests that confirm the story’s satisfactory completion

Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:

Independent We want to be able to develop in any sequence.
Negotiable Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
Valuable Users or customers get some value from the story.
Estimatable The team must be able to use them for planning.
Small Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
Testable Document acceptance criteria, or the definition of done for the story, which lead to test cases.

Why use user stories?

  • Keep yourself expressing business value
  • Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
  • Avoid the appearance of false completeness and clarity
  • Get to small enough chunks that invite negotiation and movement in the backlog
  • Leave the technical functions to the architect, developers, testers, and so on

How do I write user stories?

When getting started with stories, a template can help ensure that you don’t inadvertently start writing technical tasks:

As a <user type>, I want to <function> so that <benefit> .

Examples:

  • As a consumer, I want shopping cart functionality to easily purchase items online.
  • As an executive, I want to generate a report to understand which departments need to improve their productivity.

Try to avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system. Not all actors are end users. For example, a role could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper).

In Rally, this template should be entered at the top of the Description field. This sets the tone for the details and acceptance criteria, which will be entered below.

Click to read the full story: https://help.rallydev.com/writing-great-user-story

Agile Programming for Your Family? Bruce Feiler says Yes!

I became an advocate for continuous improvement when I discovered that when we improve processes, we also improve people’s lives. Bruce Feiler’s TED Talk on agile families is well worth your time. I regret that I did not use these techniques when my daughters were younger, but I can certainly spread the message, starting NOW!
bh 2014/10/17

Bruce Feiler has a radical idea: To deal with the stress of modern family life, go agile. Inspired by agile software programming, Feiler introduces family practices which encourage flexibility, bottom-up idea flow, constant feedback and accountability. One surprising feature: Kids pick their own punishments.

Bruce Feiler: Agile programming — for your family 

Bruce Feiler, Writer
Bruce Feiler is the author of “The Secrets of Happy Families,” and the writer/presenter of the PBS miniseries “Walking the Bible.” Full bio

Kanban for SAFe Teams

Alex Yakyma is a thought leader in the SAFe community and this is a great article on the how’s and why’s related to kanban within the Scaled Agile Framework (SAFe).


Kanban for SAFe Teams

By Alex Yakyma

Abstract

The use of Kanban techniques for managing workflow is growing in software, as well as in other industries.  Originally a technique derived from lean manufacturing, Kanban is a lightweight way of visualizing and managing work of any kind. It’s easy to adopt and provides sophisticated constructs for continuing improvement as teams master the method.

While not a software-specific method by original intent, its application in software development can be quite useful. It provides a more granular view of the flow of work through the team, illustrates bottlenecks and delays to be addressed, and increases flow by application of work-in-process limits.  Properly used, Kanban provides a powerful set of constructs that every software enterprise should be able to apply in the scaled systems context. This article describes how Kanban can used by SAFe Teams in the content of their Agile Release Train.

Continue reading

Agile Goes Big Using SAFe

This week I had the opportunity to meet and hear Dean Leffingwell talk on Scaled Agile Framework (SAFe) and its history. It was fascinating to hear him recount the early days of Agile, and how the SAFe came into existence. What impressed me most was how he continually tied Agile and SAFe back to the teachings of Taiichi OhnoW. Edwards Deming, and to the Lean concepts underpinning Agile. I am a late arrival on the software development scene, and I was working to improve First Call Resolution in an airline call center while people like Dean, Al Shalloway, and Mary and Tom Poppendieck were figuring out how to apply Jim Womack’s  “lean thinking” to software development. It was a great presentation and while I have many more questions than answers, I am sold on the concept that Agile can scale effectively.

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale. SAFe’s primary user interface is a “Big Picture” graphic (http://scaledagileframework.com/) which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level. (The image at the top right is literally just one corner.) If you are serious about process improvement in the IT space, I strongly recommend you check this out.

(http://scaledagileframework.com/)

Image-Detail of the Scaled Agile Framework (SAFe) Big Picture.

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The Big Picture describes three levels of scale:
Team, Program and Portfolio. Each of these scales the essential agile elements of Value (requirements and backlogs) Teams (from development team through portfolio) and Timebox (iteration, PSI, budget cycle). This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagility blog.


Further Reading

Leffingwell, Dean (2011).
Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise,
Addison-Wesley Professional, ISBN 978-0321635846.

Leffingwell, Dean (2007).
Scaling Software Agility, Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0321458193.

 

Bob Hubbard, July 2013

Lean Marches Forward with SAFe

SAFe refers to the Scaled Agile Framework. According to the Scaled Agile Framework website (http://scaledagileframework.com/):

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The Big Picture describes three levels of scale:
Team, Program and Portfolio. Each of these scales the essential agile elements of Value (requirements and backlogs) Teams (from development team through portfolio) and Timebox (iteration, PSI, budget cycle). This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagility blog.

Image-Detail of the Scaled Agile Framework (SAFe) Big Picture.
Detail of the Scaled Agile Framework (SAFe) Big Picture.

(http://scaledagileframework.com/)

Further Reading

Leffingwell, Dean (2011).
Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise,
Addison-Wesley Professional, ISBN 
978-0321635846.

Leffingwell, Dean (2007).
Scaling Software Agility, Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0321458193.

The Agile Family?

Yesterday’s “This will never work” becomes today’s “Wow! Why didn’t we think of this before?!” In the 80’s we heard that Toyota’s management practices will never work in the US. Toyota (and many others) went on to demonstrate how American workers were perfect for the Toyota Production System (known generically as ‘lean’). Then we heard that “Lean works in manufacturing, but it will never work in a human process.” Then a group of tech guys in 2001 got together and agreed on the Agile Manifesto. In this TED Talk, Bruce Feiler tells how he’s adapted Agile concepts to his household routine.

Can Software Development Be Agile & Autonomous?

Those of us who work in the software development world are familiar with the term ‘agile’. But for us, this term is related to the Agile Manifesto. In Vijay Kuman’s TED talk, he speaks about ‘agile autonomous’ robots. He shows that decentralized control, local information, and anonymity work in this physical world. I wonder if we could use the same principles. He notes that the larger you make the quadrotor copter, the more inertia you have and the less agile it is.  Hmmm… that sounds awfully familiar.

About this video: In his lab at Penn, Vijay Kumar and his team build flying quadrotors, small, agile robots that swarm, sense each other, and form ad hoc teams — for construction, surveying disasters and far more. At the University of Pennsylvania, Vijay Kumar studies the control and coordination of multi-robot formations.