Agile development method scrum Best Practices

Document directory

• Important Terms of scrum
• Scrum Process Overview
• Backlog-story
• Pay attention to the following points for estimation:

Emphasize some basic scrum concepts

This article only provides a full set of proven practical experience for IT managers who continuously experiment agile development methods and pursue fast delivery products for their reference. First, let me assume that you have understood and agreed with the basic concept of scrum, an agile development method. However, I still want to emphasize the following "Consensus" we have reached on scrum ":-)

The SCRUM development process usually takes 30 days or a shorter period of time as a cycleProduct owner)
Starting from offering new product specifications,Development Team)
With the product manager at the beginning of each stage, select the completed specifications. The development team must try its best to deliver results within the cycle.Development Supervisor (scrum master)
Convene a meeting every day for 15 minutes to check the progress and plan of each member, learn about the difficulties encountered and try to eliminate them.

Important Terms of scrum

Backlog-
Predictable task set, including all functional and non-functional tasks.

Sprint-
The time period of one iterative development. Generally, up to 30 days is the cycle. During this period, the development team must complete a developed backlog.

Product owner
-This role is called a product manager. He defines the product and puts forward the requirements to the development team, and finally accepts the work results of the development team.

Scrum master-
A Team member responsible for supervising the entire scrum process and revising the plan.

Sprint planning meeting-
It is held before each sprint is started. Generally, it is a day (8 hours ). The task required for this meeting is: the product owner and team members break down the backlog into small functional modules (I .e. tasks) and decide how many small functional modules need to be completed in the upcoming sprint, determine the task priority of this product backlog. In addition, the Meeting also needs to discuss in detail how to complete these small functional modules as needed.

Daily scrum meeting-
A member of the development team generally takes 15 minutes. Each developer needs to report three projects to the scrum master: what has been done today? Have you encountered any obstacles? What will we do soon? Through this meeting, the team members can understand the project progress.

Sprint review meeting-
After each sprint ends, the results of the sprint are presented to the product owner and other related personnel. Generally, this meeting is 4 hours.

Sprint pull spective meeting-
Summarize the final sprint. Participants of the meeting are internal personnel developed by the team. Generally, this meeting is three hours.

Scrum Process Overview

1. Split the backlog of the entire product into several sprint backlogs. Each sprint backlog can be completed according to the current human and material resources.

2. Hold the sprint Planning Meeting to divide and determine the tasks to be completed in the sprint, mark the task priority and assign it to each member.

3. Enter the sprint development cycle. During this cycle, daily scrum meeting needs to be held every day.

4. At the end of the entire sprint cycle, the sprint review meeting will be held to present the results to the product owner.

5. The team members finally held the sprint into spective meeting to summarize the problem and experience.

Perform the next sprint following the same steps.

Next, let's start with the topic-Best Practice Guiding Ideology

Scrum and extreme programming (XP) both require the team to complete some deliverables at the end of each iteration. Iteration is short and time-limited. Focus on delivering workable code in a short period of time, which means that the scrum and XP teams do not have time to do theoretical research. They do not spend time using modeling tools to draw UML diagrams, write perfect Requirement documents, or write code to cope with all possible changes in the foreseeable future. In fact, both scrum and XP focus on how to do well. These teams acknowledge mistakes made during the development process, but they understand:

In practice, building products is the best way to identify errors. Do not simply analyze and design the software at the theoretical level.

Scrum is not a methodology. It is a framework. That is to say, scrum won't tell you what to do. Therefore, the following scrum experience is only for your reference. You do not need to follow the steps below. In fact, if you change to a different scenario, some practical methods should be changed.

The strength and pain point of scrum is that you have to adjust it based on your actual situation.

Backlog-story

How to describe our "story" (the following "story" is equivalent to backlog), the best practice must include at least the following fields:

Id --
A uniform identifier is a self-increasing number. In case you cannot find them after renaming the story.

Name --
A brief and descriptive story name. For example, "view your own transaction details ". It must be clearly defined so that developers and product owners can understand what we are talking about and distinguish it from other stories. It generally consists of 2 to 10 characters.

Importance --
Importance. The product owner determines how important the story is. For example, 10 or 150. The higher the score, the more important it is.
Note: I have always wanted to avoid the saying "Priority" because generally, priority 1 indicates "highest" priority, but it will be troublesome if there are other more important things. What is its priority rating? Priority 0? Priority-1? Think about it :-)

Initial estimate --
Initial Estimation. The team's initial estimate indicates the amount of work required to complete the story compared to other stories.
I thinkEstimation is the most technical and uncertain part, and of course it is also part of the scrum process that needs continuous improvement.
.
The smallest unit is the story point, which is generally equivalent to an ideal man-day )".

What is "ideal person-day "?
Ask your team: "If you can invest the most appropriate people to complete this story (a moderate number of people, usually two) and lock these people into a room, there is a lot of food:-P is working without interruption at all, so it takes a few days to give a complete implementation that has been tested and verified and can be delivered?" If the answer is "it takes about four days to keep three people together", the initial estimation will be 12 stories.
Some small experiences:
We do not need to ensure that the valuation is absolutely correct (for example, it takes two days for the story of two story points), but to ensure relative correctness (that is, the time spent on Two-Point stories should be half the time required for the four-point stories). Different from "man-month" in "man-month myth ", the minimum estimation granularity of the scrum method is generally "man-day". Sometimes it can be as small as "0.5 man-day". I think it is worth discussing. This is agile enough.

How to demo --
How to demonstrate the results. It briefly describes how the story should be demonstrated in the sprint demonstration. In essence, it is a simple test specification. "Do this first, and then do that, you should get ...... ". If you are using TDD (test-driven development), this section can be expressed as a pseudo code for acceptance testing.

Notes --
Annotation. Relevant information, explanations, and references to other materials. It is generally very short.

With the above experience, we can design the simplest and most effective backlog description template, as shown below:

Many teams have tried to describe "Stories" using many fields, but they finally found that only the six fields mentioned above will be used continuously.

Internal and External Quality

I suggest separating internal and external quality as much as possible.

• External quality is perceptible to system users. User interfaces that are slow to run and confusing are of poor external quality.
• Internal Quality generally refers to elements invisible to users, which have a profound impact on the maintainability of the system. Maintainability includes system design consistency, test coverage, code readability, and refactoring.

In general, the internal quality of the system is good, and the external quality may be poor. The external quality of Systems with poor internal quality is certainly not very good.

On a loose beach, how can we build beautiful pavilions?

The SCRUM master also regards external quality as part of the scrum scope. Sometimes, for business considerations, a system version may be released first. The user interface may be simple and slow, but a clean version will be released later. The SCRUM master balances the product owner because it is the person responsible for defining the scope of the project.

However, there is nothing to say about internal quality. At any time, the team should ensure the quality of the system. There is no doubt that there is no discount. So now, so in the future, always so forever.

A typical Sprint plan meeting schedule

Sprint scheduled meeting: 13: 00-(we recommend that you rest for 10 minutes every hour)

• PM-PM product owner will give a general introduction to the sprint goal and summarize the product backlog. Set the time and place of the demo.
• At pm-PM, the team estimated the time and split the backlog entries if necessary --Further split the story into tasks ".
  Change the importance score when necessary. Clarify the meaning of each entry. For all important backlog entries, enter "how to demonstrate ".
• From to, the team chose the story to be included in the sprint. Computing productivity is used as the basis for verifying work arrangements.
• PM-PM arranges a fixed time location for the daily scrum meeting (daily meeting), if different from the previous one.

How long should the sprint be?

It takes a short time. As a result, the company will become "agile", which is conducive to the random response.

Short sprint = short feedback cycle = more frequent delivery = more frequent customer feedback = less time spent on wrong directions = faster learning and improvement

Many benefits are coming soon!

However, a long sprint is also good :-) the team can have more time to fully prepare, solve the problem, and continue to reach the sprint goal, team members will not be overwhelmed by Sprint planning meetings, demonstrations, and so on.

Product owners generally prefer short sprints, while developers prefer long sprints. So the sprint length is the product of compromise. After many experiments, we finally concluded the most popular length:Three weeks
(Of course, this still needs to be adjusted based on the actual situation of the product you are developing !). The Sprint length of most teams is three weeks. It is not long or short, it not only gives us enough agility, but also enables the team to enter a "smooth" state.

There is also an effective experience:Test the sprint length based on actual conditions at the beginning. Do not waste too much time on analysis. Select an acceptable length, and wait for one or two sprints to be adjusted.

Why do we need to determine the sprint goal?

This goal can be "earning more money", "completing the three stories with the highest priority", or "satisfying the boss ", or "make the system good enough and release it as a beta version for real users", or "add basic background system support.It must be expressed in business terms, rather than technical terms, because it needs to be understood by people outside the team.

At the beginning of the Sprint plan, this goal may seem stupid and inappropriate, but it is often mentioned in the sprint, at least everyone will not be confused about why they are busy all day.

How to estimate the story contained in a sprint

There are two proven technologies:

1. instinctive response
2. Productivity Computing

There is a simple way: Look at the team's history. Let's see how much productivity they have in the past few sprints, and assume that the productivity in the next sprint is almost the same. This technology is also called "Yesterday's weather )". To use this technology, two conditions must be met: the team has completed several sprints (so that statistics can be obtained) and will be in almost the same way (the team length remains unchanged,) to carry out the next sprint.

"Yesterday's weather" is very convenient to use, but you need to consider some common sense:

If the last sprint was poor, it was because most of the members were ill for a week or other difficult issues. Then you can rest assured that the luck will not be so bad this time, and set a high investment level for this sprint;

If the team has just installed a continuous integration system with fast execution speed such as lightning, you can also increase sprint investment;

If a new employee joins the sprint, he has to calculate the training effort and reduce the sprint investment;

How to define "done )"

It is important that the product owner and team should have a consistent definition of "done. After all the code is checked in, is the story finished? Is it still completed after being deployed to the test environment and verified by the integration test group?

We try to use the following definition:"Online at any time
", But sometimes we can say this:" It has been deployed on the test server and is ready for acceptance testing ".

If you are often confused about how to complete the definition, or the definition of "finish" in your story is uncertain, you may need to add a field to each story, the name is "What is completion ".

How to accurately estimate

If you make an estimation for the entire team, the person who has the most thorough understanding of the story will give the first speech. Unfortunately, this seriously affects others' estimates.

There is an excellent technique to avoid this-its name is"Plan card
".

Everyone will get 13 cards as shown in. When estimating a story, each person selects a card to represent his estimation of time (expressed in the form of a story point) and deducts it from the front to the table. When everyone completes, the cards on the table will be uncovered at the same time. In this way, everyone is forced to think about themselves, rather than relying on others' estimation results.
If there is a huge difference between the two estimates, the team will discuss this and try to reach consensus on the story content. They may break down the task and re-estimate it. Such a loop repeats until the time estimation tends to be consistent, that is, everyone estimates the story almost the same.

Pay attention to the following points for estimation:

1. Try to avoid technical stories.
Try to find a way to turn technical stories into common stories that can measure the business value. This helps the product owner to make a correct balance, because the product owner may know little about the technology.

2. If you cannot turn a technical story into a normal story, let's see if this job can be used as a task in another story.
For example, "refactoring Dao layer" can be used as a task in "Editing Users", because this story involves Dao layer.

3. If neither of the above is used, define it as a technical story and store it in another separate list.
The product owner can see it, but cannot edit it. Two parameters, "input level" and "estimated productivity", were used to negotiate with the product owner and allocate some time from the sprint to complete these technical stories.

How do we manage backlog?

This problem seems a bit difficult.

Using EXCEL to manage product backlog is good, but you still need a Bug Tracking System, then Excel is helpless. JIRA can be used.

So how can we bring the issue on Jira to the Sprint plan meeting and our daily work? My proposal is:
Paste the sprint backlog plan to the whiteboard!

Here is not much nonsense. Let's talk about it directly:

Obviously, this is a "healthy" burn down chart. As time goes on, the story points in person/day are basically reduced along the standard line, until "burned out "......

A typical, concise, and practical whiteboard ". Unfortunately, it describes the scenario where "the plan cannot keep up with the change"-a large number of tasks temporarily inserted block the plan, resulting in a burn-out Chart "not burning ".

In general, we put a high-priority task on it to do it first. The "whiteboard" successfully described the incorrect working order of "I picked up sesame seeds and lost watermelon.

A burn-out chart is a good thing. It allows us to find some problems in the project in the simplest way. The following tasks seem too many or too difficult, and are gradually deviating from the plan. You may need to find the problem. You may need to adjust the current plan ......

The plan below seems to be too loose. As a developer, it may be very happy :-). But what if you are a boss or a manager? Add live! Let the work of the brethren be "enriched ......
 

Finally, let's echo the above:We use people/days as the basis for all time estimation (we also call it a story point ). The minimum value is 0.5. That is to say, a task smaller than 0.5 is either removed or merged with other tasks, or the estimated value of 0.5 is simply given.
. Clean and neat.

Many of the experiences in this article come from
Scrum and XP in smoke
(Original:
Http://www.crisp.se/henrik.kniberg

), As well as my practical summary and experience.