User story-driven Agile Development (Planning chapter)

User story-driven Agile Development (Planning chapter)

Reproduced from near Agile development: HTTP://WWW.JINHUSNS.COM/PRODUCTS/CURRICULUM/?TYPE=XCJ

Agile development is now not new, we have heard from various channels of different teams to implement agile fruit, listen to feel very beautiful, come home to find that it is the team of others, combined with their own situation a look at the problem a lot. Even if you are going to try, you often don't know how to start. That's why I wanted to write this document, to find a follow Agile project management model, although we all know that there is no universal method, but on a higher level I think it is still feasible. In other words, the management model is consistent, but the approach may vary and the ultimate goal is unique: Create a high-quality team that can adapt quickly to change and output high-quality products!

What I want to share with you today is the planning process for the user story, and there will be updates on how to use the user story-driven team development process.

Main issues of user stories

The user story helps the development team understand the requirements from the user's point of view while delivering them in the context of the user's available scenarios, ensuring that the development team is able to deliver the functionality that the user cares about on a continuous basis. But in actual development, the team often does not know how to start.

How to use a good user story needs to solve several key issues:

• How to generate a user story to let the user tell the story clearly?

• How can the content of the user story be delivered to the development team in an authentic way?

• How do you convert the content in a user story to a development feature point, identify dependencies with other functional points, and form detailed product specifications?

• How do you maintain the stability of the architecture while using user stories for incremental development? Drive architecture optimization and evolution at the same time.

• How do I deliver, collaborate, test, architect, and Ui/ue in the development process as a story?

• How can you use a variety of development tools and platforms to make your development process more efficient with tools such as task tracking, branch planning, continuous integration, continuous publishing, automated testing, and more?

User stories need to be collated and the traditional needs of the collation of a very different way, traditional software development we rely on user needs, technical requirements, specifications and other tools to try to use the normative documents to solve the problem of demand collection and delivery. In this process, we translate the user's requirements into specifications that can be understood and implemented by the technology. For those who have become accustomed to this way, the way to use the user story needs to be transformed into a larger mode of thinking, we often encounter the question is that the use of user stories do not need specifications? In fact, the first thing we need to know is what the user story is.

What exactly is a user story?

You may think that since we use user stories to replace traditional needs, user stories are the way to record requirements. In fact, the user story is not used for writing, but for discussion and tracking.

• Using the user story, our goal is to allow users to naturally tell the needs, so as to ensure the authenticity of information. Because any software PRODUCT is designed to help users accomplish a certain task, it can be said that any software product or system through the interaction to solve the problem, and the interaction between the two may be human and system, may also be the system and system, may be modules and modules. In this sense, any requirement is actually the way in which an individual (human, system, or module) interacts with other individuals in the process that we want to behave. The 3 key points of a user story: people, processes, and purposes, which can help us to articulate this behavior. In the story-telling process, we should focus on the main story, not how it is done.

• Once the user has made a clear story, the next step is to produce the corresponding functional points that can be developed. Here we need to focus on how to achieve. In general, it is difficult for us to satisfy a user story with a function point, which must be done with a different function point. But we still have to make sure that the scope of the discussion is only around the current story, when the technician is very prone to divergence and will consider some of the current feature points, but not related to the current story, such as: This feature may be used later, so we have to do so and so on. At this point, the user story can play a role in controlling the scope of the discussion. You may think that the technician's perspective is right, because scalability, reusability, etc. are the basic principles of software design. But we should look at these issues from a development perspective, assuming that other user stories that we can foresee do affect this function point, then this consideration is OK, but should be considered when discussing the user story, and if we have no other predictable story that will affect the function point, Then these so-called extensibility reusability designs are wasted, because you don't know if you'll need them.

• After discussing the function points and entering the development, the user story is the leader that controls the development progress and delivery progress of the technical team, i.e. we should develop testing and delivery according to the story. This ensures that our delivery is always consistent with the user's expectations, and that all development, testing inputs can generate user-approved value. This time the user story plays a role in tracking and driving the development process.

From the above analysis, we can see how the user story is not important to write, it is important that it drives the process, through this process, we can put the user and the technical team closely together, and let everyone produce a unified understanding of the delivery content. So, a user story is a communication tool, not a tool or requirement template!

Who does the story tell?

Before we really start to tell the story, we first want to make sure that the right people are involved. For planning a product, you need at least: an end-user representative, a product manager (or a POS like scrum), a project manager (or a scrummaster like scrum), a technical backbone in the team (those familiar with the implementation of the business, The technical backbone can also be divided into architectures to develop and test three people with different skills in the technology or system they are familiar with. In this way, you need at least 6 people to participate in the storytelling process (unless some people can replace each other).

Your story is for everyone to listen to, but also hope that everyone can be in the story when the input, not just listening.

• End-User representation: These people are usually the protagonists of storytelling because they are the ones who know the most about the story. But end-user representatives can only use the user's perspective to describe the story, where many technical details are missing. As they begin to tell stories, technicians need to add to these details and expose the complexities that come after stories that may seem simple from a user's perspective.

• Product Manager and Project manager: These two members are basically the role of the Facilitator, the general product Manager (PO) biased towards the user, the project Manager (ScrumMaster) biased toward the team. We hope that their tendencies can be reflected in the discussion process, the priority of the story, the importance of the degree of difficulty, such as the realization of a summary of the problem to form our project plan. At the same time, the process of the story discussion is generally conducted in the form of meetings, these 2 people should appear as organizers of the meeting (host), to guide the team to effectively complete the discussion process.

• Technical backbone: First, the technical staff should be clear that they are the protagonist, and not just audit. A lot of people have this experience, obviously a very simple function, why do it will be so slow? There are 2 reasons for this, the first is that the user does not have this so-called "simple" function to understand, the second is a user "simple" function, for the technology is not so simple, but this information is generally difficult to understand the user, so a lot of technology is inclined to do not say or say very little. The result is a mismatch between the two sides ' perceptions of difficulty. The technical backbone participates in this storytelling process, mainly to help users understand the story from the perspective of technology realization, and also to be able to understand the technical realization of the idea.

How to tell a story?

The story-telling process is done in 3 steps: To find clues----draw the main line, normalize

Find Clues – Draw the protagonist of the story

Users don't know where to start telling stories, which is the first question we'll encounter. In fact, the user's inner feeling is like watching a movie after walking out of the cinema, trying to tell a friend who has not seen the film. Think about how you're going to get started in this scenario. For example, people have seen the big talk of the West, so the way to tell the story is that the Monkey King in 500 years ago how how ..., and then the Purple xia Fairy how how ... You'll find that you will always start with a character. In fact, let the user tell the story of the same way, we first want to guide users to tell the story of who have. A movie is the result of the interweaving of multiple characters ' story lines, and a product is the same. With these characters, we have a clue that we can draw a story.

Here we can use 2 tools to help find clues: Impact map and user portrait (1, 2)

You will find that when the team starts to organize different types of users, they have started to tell the story naturally, because to make a character clear, you have to think about what he is going to do, and the story naturally comes out. But at this stage, we should not be too divergent, it is clear that our purpose is to organize the user portrait, as long as the boundaries between different user types are clear, you can end, do not dwell on the details. In addition, in the follow-up process, we will also find that some of the roles need to be added, then say.

Finally, each user type We've sorted out is glued to the left-hand side of the whiteboard with an instant sticker, such as:

In general, I will place these sticky stickers as far away from the end user as possible, while numbering each character so that it can be easily referenced later.

Draw the main line – Use the impact map to draw the story line

With the protagonist of the story, it is relatively easy to tell a story. At this stage, we want to help the team to think about every step of the story, and by visualizing it on a Kanban board, we can do that. Here, we can use the simplified version of the impact map, such as:

The impact on the standard map has 4 columns, which are why who and what, and this structure is very useful when it comes to a larger and vague goal discussion, such as: strategic planning, because how and what are easier to distinguish, but when it comes to discussing the steps of a user story, Actually how and what difference is not big, if adhere to the use of normative influence map will confuse the team. So, I suggest merging the how/what. Specifically:

Why: What is our user story? Why do we have to do this story? Who: What are the characters in this story? How/what: What do these users need to do to complete the story?

Please refer to: Understanding and comparison of how to affect maps

Such as: is a standard "new user registration" User stories, we must be very familiar with. Basically this story is the browser through the login---registration, fill in information, such as verification of mail submission registration, Administrator Audit, become a registered user after the first login--perfect information. But by putting each step into the whiteboard with a card, you'll find that the whole team is well focused on the details and has a holistic view of the whole story. Without this visualization, the team could easily lose the main thread of the current discussion, stretching from one detail to the other.

Note that each user story is labeled as an ID, and it is also easy to refer to later.

You might ask, wouldn't it be better if I used a kind of mind mapping tool? The advantage of electronic tools is that it is easy to save and share information, but in team discussions, we pay more attention to the atmosphere, focus and overall efficiency of team discussions, and if we use electronic tools, we cannot allow everyone to operate on this diagram at the same time, but must be operated by one person, and others are easily distracted. If the tool is not skilled, it will delay the time. So the whiteboard is a very low tool, in fact, for the team discussion, it is more efficient than any electronic tools.

For example: This is a user story discussion that I participated as an agile coach, and you can see that everyone is gathered around the whiteboard, the whole discussion is standing, anyone can comment at any time, and with a sticky note, you can start saying, "This" step. Without a visualizer, or using an electronic tool, it would be difficult for everyone to use "this" to focus on everyone's attention, and you might need to explain what "this" is or need to be done in an electronic tool, which would be more troublesome if the operator was not the interpreter. Details determine efficiency!

Normalize – Use User story maps for functional analysis

With the story line, we can do the next function refinement. This step is actually produced in the traditional software development process of the software specification. The software specification is very important for the developer to realize the product function, which is an indispensable part of the software development. Many people think that agile development does not require documentation, in fact, this is a huge misunderstanding. But the documentation in agile development is really different from the traditional requirements document:

• Agile Development pays attention to the process of document generation and wants to ensure the integrity of content and the delivery of information in the process through transparent processes and collective discussions. There is no specific requirement for the format of the document itself, as long as you ensure that the content in the discussion is recorded.

• The document in agile development is not the subject of the demand, but the person who transmits the demand.

• The agile document is a live document, so we prefer to record the requirements through the system rather than the traditional static documents such as Word or Excel. The purpose of these documents is to help team members to recall and tell, as well as a means of process tracking.

• There are often 2 project plans in traditional software development, one listing the requirements and estimating them on demand to derive the budget, and the other is the time and resource plan, which is often planned in phases. Agile development has only one project plan, which is to organize the time, resources and track of each stage according to the user story – this is what the user story-driven agile development means.

The process of normalization can be done using a user story map, together with a discussion of each step in the story's main line, analyzing the functional points in a specific area (module) of the product, and describing the functionality in a way that the technician can easily understand. This whole process is the process of translating requirements from the user's perspective to the technical implementation perspective. In the process you will find some technical details that are not visible in the story line.

In this process, we want to take into account both the architecture and the input of the test, both of which need to ensure that the decomposition of each story meets the requirements of the architecture and can be tested from its own perspective. Because each user story travels through multiple functional areas, the architect must assist the team in ensuring the scalability, reusability, and performance requirements of the architecture. For testing, make sure that each user story is testable to ensure that subsequent test plans and use cases can be matched to the team's development process and delivered to the user individually and by story.

For example, the above user login this story into a function point, displayed on the user story map, this is the standard user story map format:

• Top 2 layers are functional areas (modules) of the product

• The function points below each module are derived from the analysis of a step in a user story

• The ID of the user story is marked on the instant sticker of each function point, so that we find a corresponding function point for the image map.

• Some of the content that is not explicitly listed in the impact map is shown on this chart, such as the content in the admin and System functions section of the

How to organize requirements seminars

The story-telling process is usually conducted in the form of a demand seminar to ensure that all the people involved are present. Since it's a conference, we have to make sure the conference is efficient, so here's a 8-point guideline for Samsung's efficient meeting:

(1) Every meeting must have a theme;
(2) There must be an agenda for any subject;
(3) There shall be resolutions on the agenda;
(4) Any resolution, there will be tracking;
(5) Any trace shall have the result;
(6) The result shall be responsible;
(7) All responsibility shall be reward and punishment;
(8) All rewards and punishments must be transparent.

We need at least the following arrangements for demand-based seminars

• Meeting Subject: XXX Product Requirement Seminar, the purpose is to discuss XXX product XXX content within 4 hours

• Conference Agenda:

• Organizer: Product Manager xxx or project manager xxx

• Participants: Business parties or end users, product/project managers, Team Technicians (architecture, development, testing, etc.)

• Discussion content (List of stories sorted by priority)

• Conference Division:

• Moderator: Rotate the organization by Product manager and project manager

• Requirement Recorder: By a person in the technical team, responsible for the discussion process of user stories and the resulting function points in detail records, form a document or input system.

• Issue Recorder: By a person in the technical team, responsible for the discussion process will not be able to confirm the field to record, form a document or input management system.

• Conference Deliverables:

• documentation or management system records generated for each user story on the agenda

• List of issues recorded during the discussion or management system records

• Next steps for the user story document, such as: Developing a development plan, budgeting, etc.

• The problem is tracked in such a way that the status of the problem list is maintained by WHO, and each issue is resolved by who is responsible for the follow-up, each issue is expected to be resolved.

The process of requirement discussion is to discuss the story and analyze the story according to the above 3 steps, we can follow the following process

• Pre-Seminar Preparation

• It is possible to brainstorm a brainstorming session before conducting a formal demand discussion, inviting users and technology to participate in the process, in which you are free to discuss. The aim is to give you an idea of the general situation of the product.

• Seminar Process

• First, the moderator (Product Manager po/project manager scrummaster) lists the list of stories to be discussed by the team, which is not discussed in detail and is designed to let you know the content and goals of the meeting and to make it easier to control progress.

• According to the list of story priority, starting from the 1th story to comb the story line, decomposition function points, and by the person responsible for recording

• Repeat the process until all the stories in the list are discussed

• Precautions

• Be sure to follow the story list one by one, each discussion will be refined to the function point and complete the record, and then into the next story discussion; do not first discuss all the story lines, and decomposition function points together. The purpose of this is to allow the team to focus and avoid distractions caused by multiple threads.

• When discussing each story, do not discuss content that is not relevant to the current thread, especially if the technical team is prone to spread from one function point to the other, as this is the product perspective of the technical team, and this diffusion reduces efficiency. The moderator should stop when he sees this, telling the team that other functional points can be left to discuss in other stories, as long as the part of the product we are sure to cover in the following story.

• You can take a short break after completing the discussion of each story, ensuring that each participating member is focused and avoids the form of a group discussion during the discussion. It is recommended that the discussion of each story stand before the whiteboard.

• The host can be rotated by PO and scrummaster according to the story, the main responsibility of the host is to ensure the smooth process, the concentration of team effort.

• Pending confirmation

• It is recommended to open up an area on the whiteboard to record the problems that the team in the discussion can not identify on the spot, and to avoid having to dwell on these issues for too long and affect the efficiency of the meeting.

The above is the process of using user stories to drive product planning and design, and I will follow up on how to use Kanban and scrum to drive the development and delivery process.

Source: HTTP://WWW.JINHUSNS.COM/PRODUCTS/DOWNLOAD/?TYPE=XCJ

User story-driven Agile Development (Planning chapter)