Now the meeting formats with Agile are very useful. So while these are guidelines, the format, the frequency, and the function of agile meetings can differ from team to team. So agile set out to be a more dynamic way of building applications. So if you want to change something go ahead and do so. I find the scrum process is the most common meeting format in play in the field. And the scrum process includes the sprint planning meeting, the daily stand up, the sprint review, and the sprint retrospective. Remember how the time constraint was the key difference with agile projects. We work to a time box. So the core construct of the agile process is working to time boxes. Let's talk about the sprint planning meeting. So the sprint planning meeting is held at a regular time, usually the first day of the sprint. And the sprint planning meeting should be attended by the product owner, the scrum master, and the development team. Now in the sprint planning meeting the product owner describes the features he or she would like to see completed in the sprint. 

The product owner is representing the customer or end user in this process. So they will explain the features from that user's perspective. This will often be in the language of the user should be able to achieve outcome x by doing action y. Once the product owner has outlined the list of outcomes that the product owner sees as the most important for our user, then the team discusses and defines the tasks that will be needed to be implement each of these outcomes. This process is essentially outlowing what is required. Now the team then reviews the outcomes and breaks these into the tasks that they will need to perform to achieve each of those outcomes. The team then makes an initial estimate of the time and the skills and the resources required to complete the tasks. 

The team then assemble the work efforts in the sprint time box and prioritorize those tasks. If the tasks look achievable in the time allocated to the sprint, then the team commits to the sprint. If the time required to achieve the task is more than the sprint time box, then the lower priority features go back into the product backlog until the workload for the sprint is small enough to obtain the team's commitment. Now while the objective here is to arrive at a lists of tasks that can be achieved, this process requires discussion and negotiation. It's all about trying to get an achievable outcome within that time box. Now let's talk about the daily stand up. So the daily stand up is a key component of the agile process. It's an unusual meeting format which can be confronting to people not used to agile or to the stand up process. 

So firstly the meeting is literally conducted with people standing up. This is so the meeting is as short and effective as possible. Now secondly the stand up can happen anywhere. So it's not uncommon to find a stand up being conducted around your desk or workspace or even in the hallway. In this daily stand up the team members gather around the task board and each talk briefly using three headings, what they have are completed, what they are currently working on, and what issues are currently holding them up. And that's it. The team members are discouraged from elaborating on other points of the project, and the stand up is designed to update other team members on progress. And most importantly for me, give the scrum master an opportunity to hear and act on any blockers that the team members are experiencing right now. Once the sprint planning meeting is complete and the team have made a commitment, the team begins to track its progress using information, charts, and boards. Now these charts should include a burndown chart and a task board. 

These charts are in my view best if they're big and visible in the shared area. So if you're using something like Atlassian Jira or any of the other agile tracking tools, it's a good idea to display these charts on a large monitor. The sprint progress is tracked using the burndown chart, the task board, and the daily stand up. These three things provide a clear picture of what's been worked on, what's completed, and what's still to be done. The task board is used by the team to track the progress of the tasks for each feature. The minimum columns we use on the task board are to do, doing, and done. The development team holds their daily stand up meeting around the task board and move items across the board when stating what they did yesterday, what they plan to do today, and what obstacles are holding up progress. The burndown chart shows the amount of work done and the amount left to do in a sprint. So the line indicating the amount of work left to do should trend down to zero by the last day of the sprint. Let's talk about the sprint review. When a sprint is completed it's crucial to review the work and request feedback. At the end of a sprint a scrum master invites all stakeholders to the sprint review meeting, and in this session scrum master and team will show and demo the features that were completed in the sprint. So feedback is requested and expected. 

And this is a key part of the agile process. If something isn't done right the team need to know immediately so they can go and fix it quickly. That's one of the best things about it. So during the sprint review the product owner records any feedback and adds any new features or changes suggested to the product backlog. Once the sprint review has been completed the development team conducts a retrospective without the key stakeholders present. Now this is to determine what the team did well, what they didn't do so well, and what recommendations anyone has for improving things going forward. So any ideas or suggestions will be implemented in the next sprint and reviewed for effectiveness in the next sprint retrospective. An integral part of the agile process is release planning. 

So release planning is a way to plan ahead with a time box that contains multiple sprints. So releases can be done at any cadence that suits. Some projects may work with quarterly releases. Some projects may require more frequent releases. The entire team should attend release planning meetings. The product owner will present the features he or she would like to see completed in the time box, but the team does to task these features out in the release planning meeting, right? The team provides a high level estimate to identify what features could be done in what respective sprint. So it's very high level. Ideally there's an opportunity to estimate how many of the identified features could be completed by the end of the release planning cycle, but it's not mandatory. 

Release planning can be feature driven, all right? So how many sprints will it take to complete this set of features, for example. They can be time driven. So how many features can we expect to have completed by this deadline? Or it can be cost driven. So knowing our current schedule what features will we have done within this budget?