- understand what to build
- identify key system functionality
- determine at least one possible solution
- understand the cost, schedule, and risks associated
- get a more detailed understanding of the requirements
- design, implement, validate, and baseline an architecture
- mitigate risks
- produce schedule and cost estimates
- develop a complete product that is ready to transition (whatever increment is ready)
- heavy on Test Driven Development
- try to construct in parallel, so break up the work into manageable chunks
- beta test to validate that user expectations are met
- deploy, and gain approval of deployment
- create a lessons learned
How are we going to use this?
We’ve completed the majority of the inception phase. We have a good understanding of the system, and have outlined a requirements document and all use cases (in the form of use case tables).
Next, comes the construction phase. This is where we will actually write code to solve the problem we’ve been given. We will intentionally break the requirements into chunks so that we can solve a chunk at a time, deliver it to the customer, and continue iterating that way. We will use TDD, so we will write unit tests for our application prior to writing the application code. We will also try to break up the work into chunks that can be worked on in parallel, and if need be we will pair program to ensure that the work is being completed in the best possible way.
Lastly, we have the transition phase. This is where we have finished the current chunk and will show it to our customer. This will likely occur during our weekly meeting with our sponsor. We will show them, get any feedback they have for us, and use that in our next inception/elaboration phases. We will also reflect on the previous phase and create a lessons learned.
We will timebox these phases so as to mitigate the risk of ‘analysis paralysis’, as another team from a previous year has warned us of this risk.