Sprint Evaluation

Assessment and rating of sprints

This section explains my way of evaluating sprints in most of my project-based teachings.

A TA evaluates each Sprint (one per week, most of the time). The evaluation will address five or six criteria and will take the following form:

Figure 1. Example of weekly evaluation (using JS)

Figure 2. The initial 6 artifacts (Source here)

These artifacts come from a course on software quality from my colleague Xavier Blanc (https://github.com/xblanc33/QualiteDev).

Sorry for the French in the linked explanations.

Figure 3. Examples of typical team profiles

Technical and user documentations (more details here)
As much automated as possible (javadoc, .md/.adoc, code included rather than copy-pasted)

How well are supported/explained the verification activities (more details here)
Address and differentiate unit tests and integration tests

How professional and automated are the build, automated testing, deploy (more details here)
Can (should?) reach a high level pretty early

Here is a typical scale:

Criterion	%
Respect for the Scrum method	20%
"Professional" character of dev	20%
Successive deliveries	20%
Tests / Documentations / Readme / wiki	20%
Code and application quality	10%
Final Customer Satisfaction	10%

I advise you to add such a table in your readme and self-evaluate your project.

Software Engineering term for Procrastination!

Have the same policy in the project:

[Fix|Feature|…] [Issue_Number]: Use a sentence with a capital letter and verb for the first word.

Avoid useless comments!

General
- The materials for the course: http://bit.ly/jmb-teaching
- The initial course about quality development: https://github.com/xblanc33/QualiteDev
Python
- Defect prediction https://github.com/awsm-research/PyExplainer