Page Operations
Browse Space
Overview of Wrap-up Week (or 'Wrap Week')
The focus of the wrap-up period is to document, peer review, integration test, fix bugs and prepare an initial scoping and task list for the next iteration.
Entry Criteria
When the Development Period ends and wrap week begins, the technical work and most major documentation on the task should already be complete. Summary Confluence pages should be largely constructed, with only minor open issues. Many task Comments will have been issued (as the work is completed), though some may be pending.
There is no option to slip the wrap week, so if the entry criteria have not been met for a particular task, that task will have to be considered incomplete, or complete with issues. On occasion the Development Manager may conclude that a short additional time (some hours, or even a day) may be allowed to complete key work before the Wrap work begins. This is unusual, because it disrupts the coordinated consideration of the team's output with the other teams.
Schedule Overview
The first day of the wrap week is for the completion of the open parts of the documentation process. Subsequent days are allocated to review and rework to completely organize the materials.
Review typically takes place over days 2 and 3, with rework completed on day 4 and 'signed off' on day 5. The Leads and Development Manager will have the responsibility of consolidating all the work into completed reports at the end of the week.
Detailed Tasks
Complete Reporting (Day 1)
- Complete Jira updates per the Jira instructions
- Complete any pending Confluence pages, including
- Iteration overview
- In-progress pages built during iteration
- Iteration summary
JIRA Task Resolution Definitions:
These task resolution categories may be used for a given task.
| Status | Technical Meaning | Programmatic Meaning |
|---|---|---|
| Complete ('Fixed') | Task satisfactorily progressed | Believe ready for next stage (next iteration or review); no risk or work remaining |
| Dropped-No Impact | Task no longer needed for some reason (overcome by events, or achieved through other means, or...) | Original goals can be achieved with less work, or through other means. |
| Dropped-May Impact | The task will not be completed at this time, but may come back to haunt us later (if task clearly is needed later, 'Residual activity' is correct assignment); this is a heads-up for management | Nominally work is no longer of interest, but this may represent 'hidden' scope reduction (e.g., the original goals may have been too ambitious?) |
| Work Remains | At least some work still must be completed for successful progression to next tasks or review | Work has gone slower than expected/ required; risk has increased (until task is resolved) or scope must be decreased |
For the full iteration, the requirements to consider a task complete are:
- it should be internally tested or verified;
- design documentation to be complete; and
- code should be complete and documented, with
- any remaining work (bugs or features) deferred by agreement of the engineering team, and
- integrated with the baseline software if that is its intended
deployment.
Iteration Summary Page
- to be described -
Review (Days 2 and 3)
The management team will ask many of the developers to review work in their IPT or other IPTs. The purpose of the review is two fold. The reviewer will learn about all the cool stuff the going on in another part of the project and the reviewer will bring a fresh perspective with new insight to the problems faced in the iteration. This is a collaborative learning experience, not a king-of-the-coding-hill competition. The components chosen for review will be the ones which stand out to the management team as important accomplishments. The process should take several hours starting from the written documentation and examining the design of the implementation. The reviewer can read the docs, hack the code, run the unit tests, try use cases, and look at the Jira task comments.
This process is not in isolation. Everyone should be available during the process, so if you don't understand something, ask the developer and discuss it. Most everyone thinks what they have been working on is really cool so ask they why they did this, or how they decided to do it that way... This should be fun.
Review Criteria
Four questions reviewer should consider as they review the products:
- Does the summary material clearly explain the work done? Is there enough context to understand the work done?
- How does this work relate to your work and your subsystem? What ideas or tools can you apply to your work?
- What issues in the content (Word, Jira, code) should be addressed, either now or sometime?
- What interesting insights, suggestions, or thoughts can you offer for the developer to consider?
Review Format
The result of the review should be a child page on Confluence with your insight on the component you reviewed. This should summarize the topics above. If one a unit test fails that can be captured, but don't hunt for corner cases in a prototype code - do onto others and all that...
Rework and Report (Days 4-5)
The developer should read their review comments and discuss them with the reviewer. Any outstanding issues should be addressed in the original material. Mark these as ('Done') at the end of the reviewer comments.
The management team and leads will collect the resulting comments and rework into a single report, reviewing it for completeness and following up with individual participants.
Transition Activities
As developers complete the review process there may be some lag in getting them engaged in the new design period. Most of you have a sense of where you are going next or ideas you may want to investigate from the previous iteration - feel free to explore a little. If you need something to do, bring you IPT lead a coffee and ask what to do next.