Delivered once, the risk of final rework is greater

Demand does not change frequently and delivery time is not fixed.

Adapt to customer changes and deliver once

Go online quickly to capture the market, but may require a lot of rework

aka adaptive life cycle

Combining the advantages of incrementality and iteration

Can adapt to the changing environment of customers and collect customer feedback in small iterations

Small iterations can be launched

Quickly adapt to changes and get to market quickly

embrace change

keep improve

As a user, at the time/place, what do I want to do, and for what purpose/commercial value?

So, how do I do/how do I operate

How to verify in the end

Before work begins, you don't need to create all the stories for the entire project, just the main content of the first release plan.

The to-do list is constantly changing and improving, and can be updated, added, deleted, modified, changed priority, etc. at any time

Huge user stories, also called epic stories, are written at the bottom of the backlog

Definition of completed user story: 0/1 legal, completed or unfinished

If you don’t know where to start with the requirements, the impact map can be used as an effective input for the backlog

Content: Sort out the current product requirements list, including prioritizing and splitting it into story cards with moderate granularity, etc.

Time for grooming meeting: 1-hour timebox discussion for two-week sprint

The relationship between the grooming meeting and the sprint planning meeting: the sprint planning meeting can only start when the product backlog grooming meeting is completed

The story point estimate is a multiple estimate; it is estimated by the team;

Team velocity: the amount of work the team completes per unit of time

Average story points completed per sprint

Story points are a way to measure the size and complexity of user stories, not their duration

Traditional project plans are measured in hours, days and weeks

Reality: To avoid inaccurate estimates or over-promise, the estimator will eventually give you a time frame

No need to worry about the accuracy of the estimate. Get to work quickly

Teams don’t confuse estimates with commitments

Estimating Poker

T-shirt estimate

Affinity size estimation

M: Must do

S: should do

C: could be done

W: won't do it

Basic needs: must (priority development)

Performance needs: The more the better (get as much done as possible)

Pleasure needs: high satisfaction

Divided into 100 points each, they can use these points to vote for the most needed needs

Based on customer judgment, estimate to maximize product value

Continue breaking down user stories into activities

Team members determine the division of activities

What did I do after the last stand-up?

What should I do after this stand-up meeting?

What obstacles, risks or problems have I encountered at work?

Srcum task board

burn down chart

Ignition chart

risk burndown chart

Kanban

Kanban board vs task board

Team demonstrates features completed during sprint

All team members are required to participate

Everyone can be invited to participate

PO is responsible for accepting or rejecting stories

A general guideline is to present the team's work product at least once every two weeks. This frequency is sufficient for most teams so that team members can get feedback that prevents them from going in the wrong direction.

What did you do well in this sprint?

What can we do better in this sprint?

What areas can we improve in the next sprint?

Find qualitative (people’s feelings) and quantitative (metrics) data

Use this data to find the root cause

Design countermeasures and formulate action plans

Purpose of the meeting: This is not to blame, the review is to allow the team to continue to improve

Focus: The team discusses priorities together and focuses efforts where they are needed most (focusing on a few improvements is enough)

The conclusions of the meeting should be tracked in a closed loop: they can be placed in the product backlog, determine the measurement results of each improvement, and verify whether each improvement is successful.

Frequently integrate work into the whole

End-to-end information uses system-level testing: a test of the entire system

Use unit testing for building blocks: Inspect and verify the smallest testable unit in your software

System integration testing: Based on unit testing, all modules are assembled into subsystems or systems according to design requirements

Smoke testing: a rapid basic functional testing and verification strategy for software version packages during the software development process

Regression testing: After modifying the old code, retest to confirm that the modification did not introduce new errors or cause other code to generate errors.

Automated Testing: Automation of Software Testing

The team discusses acceptance criteria for the work product together

Team creates automated tests to meet standard requirements

TDD: Before developing functional code, write unit test case code first. The test code determines what product code to write.

BDD: Use natural language or natural-like language to describe and write test cases from the perspective of functional users by writing user stories or user use cases.

Detect unknown situations in systems, technologies and application areas

Useful for learning, used when the team needs to learn some key technical or functional elements

Technical debt is caused by teams intentionally making poor technical decisions for short-term project gain.

The solution is refactoring and agile modeling

Two programmers work together on a computer, one typing code while the other reviews each line of code he enters. The person who enters the code is called the driver, and the person who reviews the code is called the observer (or navigator). Two programmers often swap roles

Any team member has permission to modify any code, whole team ownership and accountability

Different agile method options are provided based on the two dimensions of project size and project criticality. For example: C6, D6

Establish a feature list, scale and design based on features

Set cost, quality and events from the start, then leverage formal scope prioritization to meet these constraints

Taking architecture as the core, focusing on database design, and emphasizing communication with users

A technique used by two or more Scrum Teams rather than one large Scrum Team, where a team contains 3-9 members to coordinate their work

Focus on detailing practices, roles and activities at the portfolio, project and team levels. Emphasis on organizing the business around a focus on delivering a continuous stream of value to customers

A multi-team Scrum framework that can be applied to agile teams consisting of 20, 100 or even thousands of people, all working together on a specific shared product

A framework designed to apply the Scrum methodology through a more holistic organization rather than individual product development layers

A process decision-making framework integrating multiple agile best practices in a comprehensive model

Factors influencing change

How to create an agile organizational culture

Agile PMO

supplier

Fast and successful delivery

A team that already has agile characteristics

geographical location

Functional structure

Project deliverable success size

Project staff allocation

Purchasing-heavy organization

Characteristics of change readiness: management willingness, employee awareness, talent capabilities, etc.

Characteristics of remaining obstacles to change

Active and clear management support

Use change management experience to drive

Driving agile practices project by project

Incremental introduction

Demonstrate and guide agile techniques and practices

Realize project value delivery

Help customers realize value quickly and efficiently by thinking and practicing some innovative ideas and perspectives

Be familiar with knowledge beyond project management itself to meet different project support needs