Agile practices in project management are worth learning from product managers

the authors will use their own company's project experience as an example of how the agile practices used primarily in the company's day-to-day delivery projects help teams achieve maximum value. although the content of the article is based on the project manager, the agile practice in project management is worth learning from our product managers. enjoy~

as project managers, we have experienced different projects, but we are always stuck in similar dilemmas. for example, here are three typical challenges:

• team goals are inconsistent
• team members are unfamiliar
• information is not released smoothly
• if we allow the problem to exist, and do not summarize and refine in each project, we will repeatedly wander into the reality of fullness and bone.

agile thinking and practices provide us with the possibility to solve specific challenges encountered during project delivery.

agile project management – success in pursuit of maximum value

when we talk about agile project management, we have to talk about the difference between waterfall development and iterative development.


everyone knows that waterfall development is characterized by large batches, slow flow, and the pursuit of work integrity at each stage, but because of its lack of parallel iteration concept, the response to change is necessarily slow. iterative development compensates for this weakness. in the iterative development process, the entire development work is organized into a series of small, fixed-length (usually 2 weeks) projects, which we call a series of "iterations". each iteration includes requirements definition, requirements analysis, design, code implementation, and testing.

in this way, the development work can be started before the requirements are fully determined, and part of the functional development of the system is completed in each iteration, and then the requirements are refined through customer feedback and a new round of iterations begins.

Agile development implements requirements in stages by progressively refining and iteratively moving forward. For example, we first locate a small number of core functions from the overall functional planning, create a minimum viable product (MVP) that can basically operate and be valuable to users, and then quickly iterate on development, listen to user feedback, and adjust the functional planning in a timely manner.

i once heard a colleague talk about the similarities between the agile team and the journey to the west team in a training session, and he thought that tang monks and apprentices can be seen as a full-featured team in agile: the team has a common goal - to get the true scriptures; they have gone through 9981 difficulties, like 9981 iterations, each successful fight is a delivery; in the process of continuous iteration, the team continues to collect feedback, continuously improve, and complete the final goal step by step. obtaining the scriptures means that the delivery of the project has been completed, and the team's ability has been qualitatively improved. it was a wonderful result.

the delivery of project results and the improvement of team capabilities are the most desired goals of project managers in project management. traditional project management is defined as "meeting or exceeding set requirements and expectations under limited resource constraints". one sentence sums up the iron triangle of traditional project management: demand is scope, resources include time and cost.

so, is this definition correct?

everyone has seen the movie titanic, and if we apply the above definition of "scope, time and cost", titanic will be judged to be a failed project. why? the film was postponed several times during filming, and the budget was much larger, which was a failed project in terms of both cost and time. but we all know that titanic is still an insurmountable box office myth.

it can be seen that the "traditional project management triangle" concept in the left figure ignores the important factor of "value". the "agile project management triangle" in the figure on the right emphasizes that teams should receive real feedback from the market to help agile teams deliver valuable software continuously and early.

in the pursuit of value delivery, we are increasingly finding that there is a vital part of agile project management – people, our team. value is created and served by people, and many agile practices revolve around people. we're trying to find a universal way to maximize human energy. the most valuable people in the future society are characterized by creativity, insight, and perception of customers, and we believe that such a team can create the greatest value.

the following will use my company's project experience as an example of how the agile practices used primarily in the company's day-to-day delivery projects help teams achieve maximum value.

user stories

User Story is the foundation of agile development, which describes requirements from the user's perspective. Software development is to realize the commercial value of the product and meet the needs of users. As long as the requirements are clear enough and everyone understands their specific content, the team can simply and effectively translate the requirements into code that can be implemented, tested, and published. In order to achieve this goal, a way needs to be found to describe the requirements so that everyone can have a common understanding of the scope of the task. In this way, the team will have a common definition of task completion, and there will be no similar problems such as "what you did not do what I asked", "I forgot to tell you this requirement".

User stories reflect user needs and the commercial value of the product, while defining a series of Access Criteria (AC). The user story is only truly completed if the team completes the work that matches the series of AC. A user story typically consists of three elements:

• role: who wants to use this feature;
• activity: what kind of function needs to be completed;
• business value: why this feature is needed and what value does this feature bring.
• user stories can be presented in different forms, and here's one:

as a > < a certain type of user persona, i < > to achieve certain purposes so that i can get < > of business value.

so once the user story is determined, the functions it will implement, the scope of requirements, and the amount of work required will be confirmed. all the developer has to do after that is to develop based on the content of this user story, and the user story is only completed when all the ac is covered, the tester completes the test, and finds that all the functions are testable and operational.

estimate and iterate planning

Estimation: The team should have a clear idea of the amount of work required to implement a user story before they start developing the user story feature. As Martin Fowler puts it, "Estimation is valuable when helps you make a significant decision.". An informed decision can only be made if the team has a clear understanding of the amount of work it takes to achieve a goal and the "benefits" of completing it.

as teams prioritize work and plan iterations, business analysts need to know the cost of each user story, and team members need to know the value of each user story. there are many ways to estimate the amount of user story work, one of which is to write the number of points needed to complete the user story (estimated according to the complexity of the user story) to the corresponding story card. estimation can help teams have a better understanding of the upcoming user story, future architectural direction, and code base design in different ways. the number of points that can be completed in an iteration can be estimated. there are also tools that can also be used to count the number of points completed by each iteration in the past, such as a burn down chart.

as long as the whole team works together, estimation itself can become a meaningful activity. it helps the team to improve understanding and ensures that everyone on the team agrees on the scope and value of the requirements to be delivered. what makes evaluations even more interesting is that instead of using simple continuous sequences of numbers, such as 1, 2, 3, 4, 5, etc. – instead take a form that approximates the sequence, like 1, 2, 3, 5, 8, 13, etc. (as seen in the da vinci code), the larger the numbers are, making it easier for the team to distinguish which story is smaller and which is larger.

When doing Iteration Planning, teams need to prioritize from the perspective of customer value dimensions and technical risk. In the following diagram is one of the commonly used tools, the requirements priority matrix.

iterative meetings and feature demos

there's an agile manifesto: customer collaboration is better than contract negotiation. there is a role in the agile team called business analyst (ba), whose core responsibilities are to ensure that the business requirements are clear and transparent, that the development team has sufficient understanding of the business, and that these pending user stories are prioritized to drive the team's development in the form of task cards.


Iteration meetings (IPM) typically occur on the first day of each iteration, where team members work together to develop an iteration plan. This meeting is hosted by BA, and everyone synchronizes several aspects of the content together:

• user stories for the next iteration;
• expectations and plans for the next iteration;
• assessment and summary of risks.
• different people have different understandings of the requirements, and all team members must agree on all the relevant content of the user story, the functions to be implemented, and what conditions the user story is met to complete. the main output of the iteration meeting is the user stories that need to be completed in the next iteration, which are the main goals to be completed in the next iteration.

A showcase is yet another practice in the agile development process, usually taking place on the last day of each iteration, with the goal of demonstrating working software. The team demonstrates the features developed in one iteration to the people involved and gathers feedback so that changes can be quickly responded to in the next iteration.

the station will open a card with a user story

Simply put, Standup is a team meeting together quickly (usually in front of a physical wall) where members update their status one by one. The update contains the following aspects:

• work completed yesterday;
• the work planned to be done today;
• what obstacles are faced and what help is needed;
• the progress of the user story at hand, whether there is a technical risk.
• since it is a fast meeting, the standing meeting time should not be too long, about 10 minutes is better. team members are advised to stand up for meetings, as studies have shown that when people sit in meetings, the duration of meetings is invisibly lengthened.

here are some practical principles:

• team members attend stand-up meetings, take turns hosting, and don't wait for anyone who is late – the sense of ceremony is important.
• At the meeting, each team member updates around the story card. An interesting practice is introduced – using tokens (i.e. using a physical object as a "token") where the person ready to speak first obtains the "token" and passes the "token" to the next person after speaking. The token should be eye-catching, it can be a plush toy or a hat).

Story kick-off: Before each user story is developed, make sure that BA, DEV, and QA have consistent understanding of the user story. This communication activity usually takes the form of a DEV explaining the functionality of the user story to be completed and the AC, and if any omissions are found, the BA adds them in time. Any doubts about DEV should also be raised in time and confirmed on the spot, so that these functions can be implemented correctly. If you encounter any doubts in the follow-up development, you should also find ba in time to understand clearly. QA will strictly follow AC to accept user stories.

code review and review

Code Review After completing each day's code, the development team gathers to review the day's code, which has several benefits:

• after a day of intense thinking and coding, the team stopped appropriately to look at the code written by others, and explained their own code, often to get some unexpected inspiration, perhaps to solve their own obstacles;
• understand each other's design ideas, get better suggestions and refactor ideas, and improve code quality;
• early detection of potential defects and reduction of accident costs: if the bad taste of the code and some areas that need to be improved are found at this time, it can take a small amount of time to make changes after the code review is over;
• facilitate knowledge sharing within the team.

Retrospective: The purpose of retrospective meetings is to arouse a collective awareness of the team through a new form of communication, point out the shortcomings of the team or individual over a period of time and list the corresponding actions. Continuous and effective review and feedback can ensure that the team cares about productivity and efficiency, understands its own shortcomings, and will become the starting point for the team's continuous improvement.


in addition to "project development", you can also focus on "agile maturity", "team roles and responsibilities", "personnel skills improvement" and so on. while insisting on the review, what needs to be done is to ensure the effectiveness of the review. according to the development and change of team building goals, the focus and form of the review should be continuously adjusted to ensure that the review can be targeted to find the team's defects and translate into practice. long-term effective reviews and correct review outputs can also continuously improve the sense of security and trust within the team.


There are many forms and methods of retrospectives, the most common being "Well & Less Well".

maximum visibility

kanban originates from lean production practices, and agile borrows the visual management concept behind it to form a visual management tool with its own unique style.

in agile projects, a "big chart for everyone" hanging on the wall is a common practice that is used to share and visualize the status of the project. for example, a physical wall that represents the status of a project typically consists of three elements: time, task, and team.



in addition to representing the status of the project, the project team visualizes other elements, such as the rules that the team should adhere to, the sharing of experiences on the project, and the milestones of the project.



in general, through consultation between connected teams and individuals, individual activities can be identified over time to come, and correspondingly, how success is measured, and then visualized, reviewed and adjusted again every period of time. with this visualization, it becomes easier for the team to align goals and to constantly cultivate and deepen responsibility.

the benefits of visualization are:

• the day-to-day work is transparent, all the story cards during the iteration are visualized, and team members can always know what needs to be done and what will be done at any time. because people are more responsive to vision, the visual story wall immediately focuses the team's attention.
• exposing problems encountered during iterations can encourage team members to actively discuss solutions together at work.
• teams can also understand what help is needed based on the current progress and the problems encountered, better allocate resources, and reduce the risk of development progress being delayed.

communicate the plan

self-organizing teams in agile are actually the result of agile, not a prerequisite. the process of implementing agile is also the process of building self-organizing teams. each team member will also solve the problem of "what to do and how" in a self-organizing way. every day, everyone on the team keeps the other members in tune. to stay in sync, we create communication opportunities based on agile practices, which is one of the processes of implementing agile.

There is a very famous event at Thought Works called Inception. Inception is a way to start a software design and delivery project, through a centralized, interactive design workshop, to help customers agree on the scope of the project in the shortest possible time, and quickly enter the project delivery. One of inception's outputs is the Communication Plan. For example, in this communication plan, we will discuss: how often and in what form the project will be updated, for example, some major information will be updated in the form of a weekly report every Friday; when the station meeting and iteration meeting will be held, and who needs to be invited, such as the business leader, the technical person in charge, and so on.

the following are clearly defined in the communication plan:

write at the end going back to the beginning of the article, i think it is possible to map agile practices and solutions as follows:

• team goals are inconsistent
• use electronic and physical walls to display user stories, demand panoramas, and project progress burndown maps;
• align iteration plans with iteration meetings and feature presentation meetings to progress projects and identify project risks.
• team members are unfamiliar
• create more communication opportunities based on agile practices, such as retrospective meetings, code reviews, and stand-up meetings. by constantly creating such communication opportunities, team members can be more tacit.
• information is not published smoothly
• share information and develop communication plans;
• maximum visibility.

there are many types of agile practices mentioned in the article, which need to be implemented and improved throughout the team's daily activities. behavioral psychology research suggests that repetition over 21 days will form a habit. any action, repeated for 21 days, will become a habitual action; any kind of idea, repeated for 21 days, or repeated 21 times, will become a habitual way of thinking; any belief or beneficial practice, after continuous verification by the team, it will certainly become the team's belief and practice.

there is such a trick in kendo: keep, break, and leave.

shou: at the initial stage, you must follow the teacher's instructions, practice the basics carefully, and reach the level of proficiency broken: after the foundation is skilled, try to break through the original norms to get yourself a higher level of evolution

away: get new understanding and summary at a higher level, create new tricks and create new realms
most of the project managers are in the "keeping" stage: they learn and absorb the project management experience of their predecessors, and lead their teams to carry out project delivery work in an orderly manner; but they are often confused by some recurring problems in management, suffering from finding effective solutions, and having to repeat the previous confusion in new projects;


some project managers have reached the level of "breaking": they can summarize their own project management experience from the perspective of global optimization, and broaden their horizons, broaden their ideas, learn from or improve the ways and methods of project management through learning, sharing and various communication platforms, making them more suitable for the team;


the highest goal of all project managers is "away": with the continuous accumulation of project experience and the deepening of thinking about management, there is a new, higher-level, unique understanding of project management, and it is applied in practice, a unique way, so that the entire project management idea is completely new.


hopefully, more and more project managers will be able to reach higher stages. this is our constant pursuit in project management.