I've worked with several companies of various sizes, and a bi-weekly sprint schedule has been the most best way to deliver features effectively and quickly. Here is an overview of how I lead or adjust development and product teams in a technical environment.
WHEN? Whenever a big idea or potential feature is being introduced.
During a Product Kickoff, it is important to clearly address what the problem is that inspired the “idea” or “project”. Product can assess if the idea is a viable measure that can be executed or not. It is imperative that roles are assigned during this phase, so all expectations and tasks are met. Product Kick-offs are not the same as Technical Kick-offs. It does not interfere a development sprint unless developers are stakeholders and part of this meeting. When a new idea or project is being presented, Product will kick-off with the necessary stakeholders.
The stakeholders should include:
WHEN? Every second Wednesday in a bi-weekly sprint.
Design Groomings are valuable during the ideation phase, when design teams are gathering the right feedback from users and doing iterations. The primary purpose of a Design Grooming is to make sure that a design is technically feasible and executable in agile environments. Most, if not all, developers are invited to this session to see the potential features that appear. It is a good opportunity for developers to share their feedback, as well as ask Designers to clarify something confusing.
Sometimes Design Groomings are not necessary if teams are larger and can produce high-quality features within a designated sprint schedule. The Design and Product Stakeholder should be a part of this session. There should be discussion about solutions that save time, especially if a specific feature or project is expected to be shipped as an MVP. It should be documented that taking shortcuts to save time can often hurt the user experience.
WHEN? Every second Thursday of a bi-weekly sprint, before Estimations.
Technical Groomings is an opportunity for Developers to see newly prepared stories and tasks that were added by the PM. Many of them are marked "Ready for Development" and exist in the backlog. During this phase, the PM and Developers clarify all the requirements of each story and make sure the acceptance criteria is clear. Invite Design stakeholders if stories some stories are non-technical and related to front-end updates. PM can assign stories to Developers during this time. If something is not clear or assets are missing, the Developer can reject the story and it will be put back "In Spec".
WHEN? Between Technical Grooming and Sprint Planning.
After technical grooming, developers may be assigned stories that can be accepted during planning. It is the developer’s responsibility to estimate a story before planning. Estimations can be done individually (if stories have been properly assigned), or with the entire development team (preferred for smaller teams). If a story involves an extended period of discovery and research for proper estimation, then a Discovery/Research task may be created to track effort. Estimation can happen anytime after Technical Grooming and Sprint Planning. If a high-priority story is not estimated before Planning it can not be added to the sprint, so it is important to discuss priorities beforehand.
WHEN? Every first Tuesday of a bi-weekly sprint.
Sprint Plannings work better on Tuesday, rather than on a Monday because developers have an extra day to estimate high-priority stories. Estimation falls between technical grooming and Sprint plannings, and sometimes Retrospectives will consume time on every second Friday of a bi-weekly sprint. During Sprint Planning, the IT team decides which stories to move into the new sprint. All product and development teams should be invited to Sprint Plannings. All stories that are moved into an active sprint must should be estimated and groomed beforehand. It is the Developer's responsibility to accept tasks that can be completed to the best of their ability.
WHEN? Every second Friday of a bi-weekly sprint, or at least once a month.
Retrospectives are a great initiative to gather the finer issues that are dealt with in an agile environment. Retros tend to take up a lot of time (on average about 3 hours depending on team size), so unless a big epic has been completed, it is not necessary to have them after every sprint. The product and development teams should be invited to participate in retros, and retros should be led by POs or PMs. It is recommended not to invite department heads to retrospectives; it is the responsibility of PMs or POs to communicate the retrospective results to all department heads.