User story-driven agile development –2. Create Backlog_ Agile Development

The first "User Story driven Agile development –1" in this series. "To share with you the process of using user stories to help teams create requirements, in this article, let's look at how to use these user stories and feature points to form product backlog." The product backlog is a tool used in agile development to manage the list of requirements, prioritize, form iterations, and organize development/testing and delivery processes. It can be said that product backlog is the core of an Agile team management development process, and all activities and deliverables revolve around backlog. Once the requirements are clear, we must continuously track the implementation and delivery of the backlog content during the development process, ensuring that our ideas are delivered in the time and quality we want, and that we understand the deviations and make adjustments in a timely manner.

Starting at this point in time, we need to introduce electronic tools to manage our development process. In fact, each development team will use some kind of electronic tool more or less, the most estimate is word/excel/project this kind of office software, there is such as Jira, Redmine, Bugzilla and so on tool. For software development, we need to manage content including: 1 requirements/tasks/test Cases/bug/issues and other work items; 2 source code 3) various plans, including iteration plan, release plan, test plan, etc. 4 various artifacts (including: dependency/WIP/deliverables), such as: Jar Pack, War package , NuGet package, NPM package, installation package, delivery package etc; 5 personnel/team. Therefore, for the software development management system, we need at least these features: 1 work item tracking, 2 planning and tracking, 3 personnel (including permissions) management, 4 source code control, 5) automation engine.

Many agile coaches actually have reservations about electronic tools, and feel that electronic backlog or kanban tools can affect the team's sense of engagement and flexibility. I also agree with 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, the need for each team member to have a sense of participation, the need for everyone to be able to change the user story at any time, such a process if the use of electronic tools is very limited.

However, the electronic tool still has its irreplaceable place, especially when we need to carry on the continuous tracing and the data analysis, the electronic tool has demonstrated its superiority, simultaneously, if your team distributes in the different physical location, then uses the electronic tool to become one kind of inevitable. Because these scenes are the time when the physical boards are not functioning. In addition, considering the complexity of the software development process and the various parts of the relationship is very strong, if there is no electronic tools to assist, 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 lose track of the relationship between the function points and the stories, and the decomposed function points were submerged in different modules, and the user stories 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 op-dimensional legend" This book for the background of the ASP.net 5 sample application, created a number of user stories

About the "Phoenix Project: A Legend of it movement": This book tells the story of an IT manager, stepped, supported by the future director's help and his own "three-step work law" philosophy, eventually saving a long history of auto parts manufacturers. The novel reveals the similarities between managing modern IT organizations and managing traditional factories, allowing readers to not only take a hint of how to manage IT organizations, but, more importantly, look at their work environment in a completely different way from the past.

You can purchase the Chinese version of this book through the following links: 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 site prototype, with product listings, shopping carts, background management, promotional and order processing E-commerce sites such as the basic functions. You can take a look at this site and have a quick look at the features. User Stories List

Here's a list of stories I've sorted out using impact maps and user story maps, and the left side of each image is an impact map that lists a story, and the right side is the effect of the feature points that the story breaks down on the user's story map.

The above 5 user stories have broken down the function points I used different colors on the story map, you can see when the story is constantly increasing, the map will slowly become very large and complex, to distinguish the user story becomes more and more difficult. Use Team Foundation server to manage user stories

Team Foundation Server (TFS) is a Microsoft Research and development management platform that provides continuous integration from requirements management, project management, configuration (source code) management, test management, code compilation, automated testing, Complete tool chain for research and development of operational dimension Integration (DEVOPS) for automated release and deployment of environmental management. Most of Microsoft's own products are using this platform for research and development management, which also provides good support for agile development.

In the process of collating user stories, we can first use Excel to record these user stories and function points, while recording the functional area of each function point to form a document similar to the following.

In the table above, we save all the key information on the user story map with a two-dimensional table. Note When importing to TFS: The story map is actually a two-dimensional form, and the top functional area/module section is the classification of the function points, which can be expressed by using the area path that TFS has taken from it. Each story (the Why-who-how/what on the left) is a parent-child one-to-many relationship with the function point on the right, and can be represented by different levels of work items in TFS backlog, which can maintain a parent-child relationship between different levels of work items, just to keep track of this part of the 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 at the time of import.

First, create an area path in TFS with functional areas and modules that correspond to the category information at the top of the user story map

Now we can import our user stories into TFS,

For information on how to bulk import and update work items using Excel, refer to: Https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel

The backlog form is as follows, and you can see that TFS is good at maintaining the link between our user stories and the function points, at the same time also retains the function of each function point of the area, so that the user story map of the key data on a good maintenance, so that we can view from different angles and tracking.

Imported work items retain key information on the user's story map in different fields:

Of course, you still need to further refine each user story work item and the function point work item, record the information that the team produces during the discussion, for example: Each user story needs to include a user background, an operation flowchart, an interactive design prototype; Each function point needs to include a data dictionary, input and output, data validation, Interface prototype and so on. These can be filled out directly in the Description field of the work item, or in the form of an attachment to the work item for Unified preservation.

In the planning chapter, I emphasize 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 discussions so that the team can recall the details of the discussion in subsequent development. This information is not able to be expressed and saved on a physical tool such as a kanban or whiteboard, so the introduction of an electronic tool is just right.

The stories and function points we import form the backlog for subsequent development, making it easier for the team to prioritize the content, iterative planning, task decomposition, test plan formulation, test case decomposition, and so on. In other words, the subsequent software development process will follow the backlog we have imported as the main line. In this way, the team can extract the corresponding function points according to the user's point of view, also can view the function list from the product module angle and affect the user requirements of these modules, ensure the team to meet the user needs and optimize the evolution of the architecture to make trade-offs. Set up a complete requirements tracking view for the team (many teams will call it the requirements tracking matrix).

As you can see below, what we've done before is actually the building of the architecture model and the entry requirements section of the diagram, as well as the connection between the two parts, which is the source of a software research and development management system.

At this point, we have completed the user story to the Product backlog transformation, the next article will explain 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 link below to access this hands-on experiment Guide document:
http://vsalm-hols.readthedocs.org/

Resources:

About the user story map:
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