Review Criteria for "runable software" in Agile development (also on iterative mid-term Quality Control in Agile Development)

After the software is "runable", it can be reviewed and approved? This is a problem.

When I attended the scrum master training many years ago, the teacher came up with a good table. Each line is a story, and each column is roughly like this:

Encoding complete

Function Testing

Unit Test

Integration Test

Stress Testing

Automatic Test

......

In this way, the Po will tell you what each story requires. On the one hand, you will have a clearer understanding of the user stories to be estimated, on the other hand, we agreed on the criteria for the completion of the story at the review meeting.

 

This method is good, but later I found a better one: EA (a gaming company) divides all its story fulfillment standards into five levels:

1. Feedback can be provided (that is, you can play it out)

2. runable

3. Provide player rating

4. Provide the player experience (installed on the server (online games), or release a preview (single-host games ))

5. Perfect (available and available for sale)

This method can better understand the "completion criteria" from the customer's value. When you see the criteria level, you will know how to use this feature.

Of course, there is no conflict between the two methods, because the fulfillment standards based on customer value such as "feedback available" must have corresponding fulfillment standards based on implementation, for example, "Code Completion + function testing can be provided for feedback ".

 

Another topic is that with these standards, if they are used only during the final review, there will certainly be many "surprises ". Therefore, if some functions have been completed in the middle of the iteration, you can review them at any time and make improvements based on the review results. One company performs two reviews every 10 or 20 days in a one-month iteration, while gaming companies generally adopt reviews when the functions are completed. The problems found during the review are changes to be embraced (no changes and... during the iteration period) (As described in the two blog posts) Moscow will prevent the change from damaging the commitment, so that iteration can deliver more customer value.

 

 

Click to download the free agile development textbook: Martian agile development manual