Search Results for 'user story'


Story Map

Information Radiators are one of the most powerful concepts championed in agile as communication vehicles.  In many organizations, the use of information radiators has waxed over the past few years as more and more tools have locked data into monitors and tablet screens.  As electronic tools have replaced paper, putting radiators where people can see information, as they work or walk by, has been replaced by instant access (which is code for never looked at).  Product and sprint backlogs locked away into tools have the same problem as burndown charts, cycle time scatterplots or work in process aging charts that are in a tool and never looked at. Instead of locking backlogs away, create and use agile story maps to increase transparency and improve access to information. The goal of a Story Map is to present the big picture of a product or feature for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases.  Like other information radiators, the use of story maps has changed over over the last decade as the use of agile has become more mainstream and less tied to the principles in the Agile Manifesto. Over the next few entries, the Software Process and Measurement blog will revisit story mapping and explore several usage issues in today’s software development world. Before we dive into the hard parts, though, we need to revisit creating a story map.

Story mapping is a relatively simple process for visualizing and organizing a product backlog (the hard part is generally getting the initial set of features and stories). Story mapping was identified and popularized by Jeff Patton. The story map is a multidimensional representation of a product (we will talk later in this series about whether story maps work if you are not working on a product).  Looking at a map from top to bottom, large items—epics or features—are placed at the top of the map. TIme or the user’s journey through the product is used to arrange the epics or features from left to right. For example, some of the features in a users journey for a product to sell books might include book search, book page, shopping cart, and shipping. This is sometimes known as a walking skeleton.

After the features have been arranged across the top of the map, user stories and enablers are arranged below the feature in “priority” order. Priority can be influenced by value or the order in which product owners and product managers want the software delivered (minimum viable product and/or release planning). For example, the epic “buy a book” might include a feature “shipping” which might include stories such as “search for shipping methods”, “display estimated shipping cost”, and ‘select shipping method’.

In July 2013 we described a simple process for capturing epics and building a story map.  Story maps are a simple visual representation of work. Real life adds significant complications to the mix, such as distributed teams and work that is less product or feature-oriented.  Deciding the right scenarios to use story maps should be part of every agile team’s workflow.

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 481 will feature our essay on the Life Cycle of A User Story.  A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word ‘user story’ gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story. We zoom in from 40,000 ft down to user stories in 500 or so words!  

Read other entries on user stories by following this link: https://tcagley.wordpress.com/?s=user+story

The second column this week is from Kim Pries, the Software Sensei, Kim discusses using the Extended Backus-Naur Form as a tool to extract information out of nebulous text.

Last but not least, Jeremy Berriault brings his QA Corner to the cast.  In this entry, Jeremy discusses why QAs/testers should be given space to manage their own workflow. Jeremy has recently moved the QA Corner to https://qacorner.blog/

Re-Read Saturday News (more…)

User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality.  That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!

All three concepts are important in order to use the concept of user stories in a dynamic environment where agile and lean work is pursued.  An example is helpful to see how a user story hierarchy, flow, and states fit together.    In the following example, we will follow an automotive example to highlight the user story hierarchy, how the item impacts the user story flow, and which user story states apply to the hierarchy.  (more…)

Some states are entrances!

User stories are a way of stating requirements.  Ron Jefferies coined the meme, the Three Cs to describe a user story.  The 3 Cs are:

  1. card,
  2. conversation, and
  3. confirmation.

The idea of a card was to keep the user story short to avoid making the requirement overly complex and to avoid analysis paralysis. Because the card was a short statement of the user story, conversations are required to expose the nuances of the user story (note: nowhere does it say NOT to document your conversations. If someone tells you not to document your conversations, forget them!).  Finally, the third C, confirmation equates to testable statements that allow the team to know when the user story is satisfied. User stories might begin as nebulous statements, however, when groomed, a well-formed story provides strong guidance on the business need to be addressed.

User stories pass through four basic states. (more…)

The current is just below the surface!

Where do user stories come from and where do they go?  Agile or not, the requirements, needs, and nuances of users and customers need to be collected, written down, prioritized, and groomed.  Even though this process sounds linear it usually happens over and over again during the cycle of value delivery.  The of techniques for gathering requirements and translating those requirements into products, features, epics and user stories are varied, and we will explore them. However, first, we need to define the typical path.   We will pick the journey up after strategic definition/vision (described in our article on hierarchy)  has been identified just as or before product definition.  Here is the basic flow: (more…)

Differing definitions are a lot like swimming without a lifeguard!

A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word user story gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story.

The basic life cycle of a user story includes the following states: (more…)

Index cards

Index cards

As noted in User Stories, Ron Jefferies, Agile consultant, suggested that there are three attributes of a user story: the Three “C’s”. They are card, conversation and confirmation.  One of the earliest instantiation of the user story was as an index card. The use of card served as a constraint, which enforces brevity, increases the flow of work and reenforces the need for conversations.

Most classic methods mandate that requirements are documented early in the project and that they are as complete and detailed as possible.  This means that individual requirements tend to have a significant word count.  I have read (ok, and helped write) use case documents that exceeded 20 pages.  Substantial portions of those documents were done as requirements.  Written words only convey so much understanding and the marginal utility of adding more words is generally low.

Smaller pieces of work can be completed more quickly than larger pieces of work (assuming the same level of complexity).  Additionally, small pieces of work are easier to understand, therefore need less investigation. Also, since they can be completed more quickly there is less of a chance being interrupted for a higher priority piece of work. Due to the speed with which the story can be completed,  you can confirm that the work does what is expected and generate feedback faster too.

Because stories do not pretend to be complete they not only invite conversation, but rather require it. Conversations are exchanges of thoughts, opinions, and feelings that take place as the stories are estimated, planned, analyzed, developed and tested.

In order to attain these benefits a story card need to include:

  1. User Story – The simple need, generally in the “Persona, Goal, Benefit” format.
  2. Acceptance Criteria – Acceptance criteria guides the team to deliver the functionality that the user actually needs and wants. Each story typically has two to five acceptance criteria. More is generally an indication of the need to split the story into smaller pieces.
  3. Estimated Size – The relative size of the story allows the team to determine whether they can accomplish the story during the sprint. Sizing mechanisms, such as Story Points, Quick and Early Function Points or Ideal Days, are used to generate velocity and are used in both sprint and release planning.
  4. Annotations – Annotations, including clarification and other information, are needed to help the team deliver value.  Examples of annotations that can be added to a story as it evolves might include wire frames or paper prototypes.

Software tools have reduced the story card to a metaphor, in some cases. However the concepts of brevity, granularity and conversation are just as relevant, whether we are using a 3×5 piece of paper or a software tool.

Today we have a guest post from Jeremy Berriault.  Jeremy is a columnist on the Software Process and Measurement Cast and the author of the QA Corner blog. He is a professional tester and is currently a QA manager.  During a recent recording session, Jeremy and I talked about using story maps in testing.  That discussion resulted in this guest post.

Guest Post: Story Maps for Testing

The use of story maps has been picking up speed and the use of them have proven to be a good tool to start linking items up so that there are no surprises down the road.

From a testing perspective, I feel, this is something that should be looked at as not only helping see what the bigger picture is, yet also identifying areas to simulate early so that the teams can prepare.

Barry Overeem’s article https://www.barryovereem.com/the-user-story-mapping-game/, has a nice description of how it all works, along with a nice picture of what one would look like. Yes, the intent is to ensure that features are not done sooner than any other dependent tickets, which is a good thing. When I talk about setting up simulations, it is more about not waiting of those features if the scheduling of the development in the release is not fully aligned. From a quality standpoint, it is making sure things are smooth.

Now imagine using string (well virtual string if your map is online) to connect the tickets along with the deliverables. It could end up like a conspiracy theory wall. Which in the end it is ok since you will now have a good path of where and when you can focus attention and see where help might be required early.

For me I see this as another tool in the toolbox to get things straightened out. I remember the days of 80-page requirement and doing something like this to identify where I need to plan things out and when. A nice graphical view allows for easier consumption and not missing something. Which helps with early detection and making the appropriate changes.

The way I see it there shouldn’t be one ticket that is not linked to another in some way. Something always builds onto another one. Same as how I talk about test case building. To keep it modular and easy to use, a test case should have the output of a different case to feed into another. If you think about it you will have only one test case where that would not happen, the initial main case to get the system going, unless you get granular (which is a bad idea for testing functionality and should be focused on Unit testing).

From a test planning view, you would have a second “map” of just test cases that should overlap over the product story map. With the exception that there will be a lot more connections on the test case map. Now all that is left to do is plan out the simulations (Data, SOA, Files etc…) and get to work.

Both maps together would then help reduce the risk of having an “oh crap” moment late in the release cycle when something new is discovered or not thought of. Work smarter not harder, correct?

 

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Now on Spotify!

SPaMCAST 527, is our last podcast of 2018.  We say goodbye to 2018 by talking about user story maps.  User story maps are both versatile and an underused tool. Perhaps something that we can address in 2019?

We also have a visit from Susan Parente.  Susan brings her Not a Scrumdamentalist column to the cast to discuss agile risk management.  Risk management is a requirement for any form of work. Why do some in the agile community feel it is not needed?  

Re-Read Saturday News
We are re-reading Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along).  This week we move through three chapters. These three chapters continue to show the same pattern of abuse of the truth and employees that we have seen in other chapters. Arguably, conflating Theranos’s mission with a religion (chapter 14) might take the story to a new level of crazy but it is only that, a new level.

Week 10 – Chiat\Day, Going Live and Unicornhttps://bit.ly/2SrRpGv (more…)

A Map

Map!

In response to the recent articles on story mapping, I was asked, “When don’t I use a user story map?” As with many powerful tools, it is easy to want to use story maps in almost every situation; however, there are a few scenarios where story maps are at best overkill or at worst might be wasted overhead.

Small, low complexity efforts. Work that only impacts a small piece of functionality rarely needs the overhead of a story map.  While every team/person has a different perspective on what is small or low complexity, I suggest one basic rule, if the output of the work is a product, feature or application, however small, create a story map to guide the work.

Disjoint accumulations of work. A classic approach in many development organizations is to gather several pieces of work together (often only loosely related) and then to call that work a project.  The whole package might be large and/or highly complex; however, the lack of cohesion between each piece of work is a problem. Creating a story map in this scenario makes little to no sense.

Operational work. A story map for installing servers or scanning documents does not make sense.  In operational scenarios value stream or process mapping are significantly more useful.

A request to all blog readers and podcast listeners –
Starting next week we are going to start a process of picking both the most overused and favorite agile saying.   I have a list, but before we start, if you have a favorite please add it to the comments or email it to tcagley@tomcagley.com.