Project Management for Professional Ionic Applications
Tools, techniques, and processes to manage a professional grade project
Sprint One Review
Conducting the sprint review/retrospect
PROModule Outline
- Source Code & Resources PRO
- Lesson 1: Introduction PUBLIC
- Lesson 2: The Agile Methodology PUBLIC
- Lesson 3: Project Planning PUBLIC
- Lesson 4: Initial Client Meeting PRO
- Lesson 5: Planning and Prototyping PRO
- Lesson 6: Diagrams and Documentation PRO
- Lesson 7: User Stories PRO
- Lesson 8: Project Management Overview PRO
- Lesson 9: Setting up the Project PRO
- Lesson 10: Continuous Integration PRO
- Lesson 11: Cypress Dashboard PRO
- Lesson 12: Continuous Deployment PRO
- Lesson 13: A Change Request PRO
- Lesson 14: Planning the First Sprint PRO
- Lesson 15: Merging with Pull Requests PRO
- Lesson 16: Configuring CI for Firebase PRO
- Lesson 17: Sprint One Review PRO
- Lesson 18: Sprint Two Review PRO
- Lesson 19: Sprint Three Review PRO
- Lesson 20: Conclusion PRO
Lesson Outline
Sprint One: Review
We have clearly not finished all of the user stories we had intended to implement for our first sprint but, nonetheless, the time for our sprint has expired. This happens, and it is why the review and retrospect are an important part of our Agile process.
We aren't following a formal Scrum process, we are just using some general ideas from Scrum and Kanban to help guide our project management process. We talked about this in a bit more depth previously, but the general idea with a sprint review and sprint retrospect is that the review focuses on the product itself and feedback from stakeholders, and the retrospect focuses more on the development team and its processes. We will sort of just be combining both of these concepts into a single review.
One key thing we will want to consider is whether we deliver an iteration of the product to the client at this point in time for not. The general process we are following for the development of the software is:
Backlog > Sprint > Review/Ship (maybe)
We have set up our CI/CD processes such that delivering the current iteration of the project to the client is as simple as clicking the publish button in Netlify. However, we might not want to do that for every iteration (although generally we probably should aim for that).
Our sprint reviews might typically include activities like:
- Covering what user stories were and were not completed
- Consider what went well and what didn't
- Consider any ideas for improvements to the development process
- Generally reviewing the current state of the project
What exactly this looks like will depend on you or your team. If you are working as an individual then this is just going to consist of some self reflection/planning. If you are in a small/informal team this might take the form of a short discussion. If you are in a larger team this might be a more formal process, and might be broken up into a more strict review/retrospect format.
Let's revisit what our sprint consisted of originally:
- #21 feat: log in to the application using my Google account from any device
- #1 feat: record a client's details
- #2 feat: see a list of all clients
- #3 feat: edit a clients details
- #5 feat: access the full details of a specific client
Thanks for checking out the preview of this lesson!
You do not have the appropriate membership to view the full lesson. If you would like full access to this module you can view membership options (or log in if you are already have an appropriate membership).