Once the overall project tasks are prioritised it’s on to Sprint Planning. Each sprint will take 2 weeks. The sprint starts off with Threat Modelling. Threat Modelling is a process where structural vulnerabilities can be identified, enumerated, and prioritised from a hypothetical attacker’s point of view. Not all sprints will need to look at this in detail but it should be discussed at the beginning of each sprint to understand if any vulnerabilities can be identified, worked on and resolved in the current sprint.
Once the tasks/tickets have been created and picked up by the team members the sprint kicks off. Development, unit testing and code reviews take place daily within development teams and any code changes being reviewed will have an associated ticket. Review changes are kept small to allow developers to review code quickly and find potential issues easier. A team stand-up takes place each morning to share the current status of the sprint and to identify any issues or blockers
At the end of each sprint a demo will take place in front of the stake holders and any other interested parties. This is an excellent opportunity for the stake holders to understand how the system will operate and give early feedback. Any issues found at this stage on the latest work can be easily fixed and prioritised in the upcoming sprint if needed. A retrospective should also take place within the team(s) to understand what’s going well, not so well and what improvements can be made.