If you are about to kick off a new agile process or a veteran on the best practices of agile and scrum you still might want to read this. The goal is to share some best practices that can be a good guide to be sure your following the right steps and not just saying 'were agile' but actually utilizing the right tools for success. Now the process you see here is really a hybrid of waterfall and agile for release planning and client communications. (It has treated me very well over the years.)
When thinking about your release cycle typically starting out with a discovery sprint to answer technical questions and getting the team up to speed is a good first step. This is commonly called a sprint 0. I strongly encourage taking a week or two to get everything aligned appropriately. At times you are pushed to skip this step and just get into the actual business value it can be skipped for small projects 30 days or less. After the project kicks off there should not be a need for this unless it was skipped in the beginning. If the project milestones and scope is constantly changing then it might not be a bad idea to do a reset on the project and incorporate a 'discovery sprint' even if your project already had a sprint 0. After sprint 0 you should be focused on completing user feedback and testing during that particular sprint or the next sprint. Once the product has reached the market then depending on what happens to the team you may need to do a new sprint 0 when the next project kicks off assuming the team goes onto a new project.
Prioritization - As you go through sprints it is helpful to prioritize the high value and high risk products in the beginning so that if you fail you fail fast. At times some of the features might be too complex for the team as it is so new or complex. For these types of projects I recommend a spike story to allow the team to do some discovery on the task prior to doing any actual coding.
Regression and Release - At times as a product matures you need to manage your releases through detailed regression tests prior to a release. This time is also valuable for any training, communications or documentation necessary prior to release.
Waterfall - Comes in with regards to specific times in the year you plan on releasing to better communicate with stakeholders. Typically used with not fully migrated development teams and very mature products.
When looking at a sprint the typical best practice I have found is a 2 week sprint is ideal. As 4 weeks is to far out even for a big project and a 1 week sprint almost goes too fast ideal but not many teams are at this level of maturity.
Sprint Kick Off - at the start of each sprint a review of stories and confirmation of points by the team. In the beginning of a project this is almost a full to half day as the backlog is groomed from future sprints this will become quicker 1-2 hours.
Stand up - daily 15 minute call 'what you did yesterday', 'what your doing today' and and 'roadblock' the team needs to be aware of. At times there may be longer discussions you can have with others after everyone is done with the stand up. Maybe a 5-10 minute conversation.
Development - Not sure that this really requires much detail as it is self explanatory.
Backlog Grooming - This is something that many times is skipped but an important step for planning out future sprints and allowing the team to start defining 'spikes' where needed.
Sprint Review, Demo and items the team did well/needs improvement - Reviewing the stories committed vs completed while also demoing the features to the business and then an open discussion with the team on areas they did well, areas that need improvement and then an open discussion on ways they can adjust. It's recommended to pick one item for the next sprint for the team to focus on. Anything more than 2 is too much for the team.
When thinking about the teams roles and responsibilities here is a good matrix guide to follow.
There are many more areas to focus on but this is enough to get things started.