User story-driven agile development –2. Create a backlog

The first article in this series, "User story-driven agile development –1." Planning chapter "To share with you how to use user stories to help teams create requirements, in this article, we look at how to use these user stories and feature points to form a product backlog." A product backlog is a tool that is used in agile development to manage requirements lists, prioritize, form iteration plans, and organize development/testing and delivery processes. It can be said that the product backlog is the core of an Agile team management development process, and all activities and deliverables are carried out around the backlog. Once the requirements are clear, we must keep track of the fulfillment and delivery process of the backlog during the development process, ensuring that our ideas are delivered at the time and quality we want, and that we understand deviations and make adjustments in a timely manner.

At this point in time, we need to introduce electronic tools to manage our development process. In fact, each development team will be more or less using some kind of electronic tools, the most estimated is word/excel/project this office software, there are such as Jira, Redmine, Bugzilla and other tools. For software development, we need to manage content including: 1) requirements/tasks/test Case/bug/issues, 2) source code; 3) various plans, including iteration plans, release plans, test plans, etc. 4) various artifacts (including: dependent packages/WIP/deliverables), such as: Jar packages, war packages , NuGet packages, NPM packages, installation packages, delivery packages, etc; 5) personnel/team. Therefore, for the software development management system, we need at least these functions: 1) work item tracking, 2) plan development and tracking, 3) personnel (including authority) management, 4) source code control; 5) automation engine.

Many agile coaches are in fact reserved for electronic tools and feel that tools such as electronic backlogs or kanban can affect the team's sense of engagement and flexibility. In this connection, I also agree that, especially in the process of creating, I do not support the use of electronic tools. The main reason is that the process of creation requires brainstorming, that every team member has a sense of participation, that everyone can make changes to the user story at any time, and that this process is limited by the use of electronic tools.

However, electronic tools still have an irreplaceable place to play, especially when we need continuous tracking and data analysis, and the electronic tools show their advantages, and if your team is distributed in different physical locations, then the use of electronic tools becomes inevitable. Because these scenes are a time when the physical board is not functioning. In addition, considering the complexity of the software development process and the various parts of the association is very strong, without the aid of electronic tools, it is difficult to support a team development work.

As I led the team to use the user story map, as the number of user stories increased, I found that the team began to get lost in the relationship between the function points and the story, and the broken down function points were submerged in different modules, and the user story began to fade away. This is a very bad omen, so I started asking the team to introduce electronic tools at this point.

Sample programs and User Stories list

In order to better illustrate this process, in this series I use the "Phoenix Project: An IT Operations legend" This book is the background of the ASP. NET 5 sample application, creating some user stories

About the Phoenix Project: A legend of IT operations: This book tells the story of an IT manager, stepped, with the help of future directors and his own "three-step work method" concept, which eventually saved a long history of auto parts manufacturers. The novel reveals the similarities between managing modern IT organizations and managing traditional factories, so that readers can not only take a hint on how to manage IT organizations, but more importantly, look at their work environment in a completely different way from the previous perspective.

The Chinese version of this book can be purchased via the following link: http://item.jd.com/10034038960.html

This sample application can be accessed from the following address:

http://pucd.chinacloudsites.cn/

This is a simple e-commerce website prototype, with product list, shopping cart, background management, promotion and order processing and other e-commerce website basic functions. You can take a look at this website and get a brief look at the features.

User Stories List

Here's a list of stories that I've used to make up the impact map and user story map , and the left side of each image is the effect of the map, listing a story, and the right side is the effect of the function points that the story breaks down on the user story map.

The function points broken down by the above 5 user stories I use different colors to label the story map, you can see that when the story is constantly increasing, the map will slowly become very large and complex, it becomes more and more difficult to distinguish the user story.

Use Team Foundation server to manage user stories

Team Foundation Server (TFS) is Microsoft's research and development management platform, which provides requirements management, project management, configuration (source code) management, test management, code compilation continuous integration, automated testing, A complete toolchain of research and development Operations Integration (DEVOPS), including automated release and deployment of environmental management. Microsoft's own majority of products are using this platform for research and development management, which also provides a good support for agile development.

In the process of organizing user stories, we can first use Excel to record these user stories and feature points, while documenting the functional areas that each function point belongs to, forming a document similar to the following.

In the table above, we save all the key information on the user story map in a two-dimensional table, which needs to be noted when importing to TFS:

• The story map is actually a two-dimensional table, with the function area/module section at the top being the classification of function points, which can be expressed using the area path that TFS brings in
• Each story (Why-who-how/what on the left) is a one-to-many relationship with the right side of the feature, and can be represented by different levels of work items in the TFS backlog, and TFS can maintain parent-child relationships between work items at different levels, just to keep track of this information
• Each card on the right corresponds to a specific functional area/module at the top of the two-dimensional table, and we can trace the corresponding information by setting the value of the area path field for each work item as soon as we import it.

First, create area paths in TFS by functional area and module, corresponding to the category information at the top of the user story map

Now we can import our user stories into TFS,

For more information about how to use Excel to bulk Import and update work items, see: Https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel

The backlog is as follows, and you can see that TFS is good at maintaining the connection between our User stories and feature points, as well as preserving the functional area of each function point, so that the key data on the user story map is well maintained, so that we may view and track it from different angles.

Imported work items retain key information on the user story map with different fields:

Of course, you still need to further refine each user story work item and function point work item to record the information produced by the team during the discussion, such as: Each user story needs to include user background, operation Flowchart, interactive design prototype, each function point needs to include data dictionary, input and output, data validation, Interface prototypes, and so on. These can be filled out directly in the description field of the work item, or uploaded to the work item in the form of an attachment to save it uniformly.

In the planning chapter, I emphasized that the user story focuses on the process it drives, not the document. However, we still need to keep a detailed record of the key information generated in the team discussion so that the team can recall the details of the discussion in the subsequent development. This information can not be expressed and saved on the physical tool such as Kanban or whiteboard, so the introduction of electronic tools is just right.

The stories and functions we import will form the backlog used for subsequent development, allowing the team to prioritize, iterate, task breakdown, test plan, test case decomposition, and so on. In other words, the subsequent software development process will follow our import backlog as the main line. In this way, the team can either extract the corresponding function points according to the user's angle, or view the function list from the angle of the product module and the user requirements that affect these modules, and ensure that the team makes a trade-off between satisfying the user's needs and the optimization of the architecture, and establishing a complete demand tracking view for the team (many teams will call Demand tracking matrix ).

See, what we've done before is actually building the architecture model in the diagram and the content of the item requirements section, and the connection between these two parts is the source of a software development management system.

At this point, we have completed the conversion of the user story to the product backlog, the next one will describe how to complete the development and test plan development, and began to introduce Kanban to track the development process.

Note: The above scenario is part of the DevOps agile Development Hands-on experiment, please click on the following link to access this hands-on lab guidance Document:
http://vsalm-hols.readthedocs.org/

Resources:

About User Story maps:
http://devopshub.cn/2016/01/10/user-story-mapping-for-the-first-time/
http://devopshub.cn/2016/01/11/how-to-create-user-story-mapping/

About Team Foundation Server:
Http://vsalm-hols.readthedocs.org/zh_CN/latest/concepts/about-vsalm.html

User story-driven agile development –2. Create a backlog