- Technology: Azure
- Sphere: Development
- SDLC: Development
- Cadence: Bi - weekly
Clarity works on a two-week (10 days) planned work schedule (called a sprint). Sprints start on Wednesdays and end on a Tuesdays. Properly planning each sprint is a vital part of every project as it will determine the work to be completed for each two-week period and give the client an estimated cost. Sprint planning should be started as early as possible in each sprint.
The Project Management team will review project priorities in the stand up on the Friday before the new sprint.
Steps for Pre-Sprint Planning Include
-
The Scrum Master (Caroline) will set up developer allocations (done in "Capacity" tab in Azure)
- Make sure to be aware of any time off or holidays
- Make sure you communicate to clients if developers will be taking time off and if it will impact their project, even if another dev is temporarily covering.
- Make sure developers are assigned development time
- If additional resources need to be allocated, PM or management assigns as ==requiremen==t time
- Make sure to be aware of any time off or holidays
-
Review client information
- Review notes from client meetings to determine client priorities and agreed-upon work items
-
Review the backlog and BRD EVERY sprint
-
Review client hours on hand
- Look in CRM or run a quick Project Status Report using Power BI (after running the utility) to determine if client has applicable hours for necessary work
- If not, approval is needed from management to move forward in any sprint with items unfunded.
- You can check developer allocation from the Sprint board in Azure by looking up Work Details as noted in the screenshot below. Allocation is shown in red if the team is over allocated based on their capacity or green if they have full or under allocation
- If allocations are high for developers, management may need to decide priority of project
- Consideration is given to the following situations:
-
Hours on hand
-
Expediency of timeline
-
Client satisfaction
-
Unblocked tickets
-
Actionable items
-
Non-bucket tickets
-
- Consideration is given to the following situations:
- Look in CRM or run a quick Project Status Report using Power BI (after running the utility) to determine if client has applicable hours for necessary work
-
Best Practices:
-
Add the EP line item to each Azure ticket to make EP Resource Allocation more efficient. NOTE: Resource Allocation is currently completed by PM Project Coordinator (Amy) after Sprint planning has been completed - but it is helpful for each PM to know how to complete this task. Also, if you happen to be in EP and notice a developer is not listed on the proper line item, you can always add that person to the line item.
-
Outline required sprint items to maintain timeline
- Review the BRD and backlog
- Gather user stories needed in upcoming sprint
- Review any unfinished items in current sprint
- Look for any QA failed items in previous sprints
- Review the BRD and backlog
-
Pull tickets from the backlog and/or create tickets
- Fill out necessary information (including tag[s])
- Add task items underneath user story items added into sprint
- Assign tickets to proper developer
-
Verify sprint information
-
Remember to include tickets for meetings, working sessions, planned assistance and / or deployments if they are applicable to your project
- Bucket tickets are a last resort and better used for balancing
-
Add total time needed for project and verify hours on hand
-
Ensure no unparented or unassigned tasks exist
-
Ensure no developer outside of the squad for sprint planning is included
-
Ensure developer tickets are not assigned to PM
-
Clarity Sprint Planning Meeting
Sprint planning meetings can fluctuate based on needs. They will either be CEF/Connect squad or project specific and will include developers as needed. If you do not see any sprint planning meetings on your calendar every other Wednesday, reach out to Scrum Master (Caroline). This meeting will be held on a Wednesday unless a holiday or other circumstance requires the meeting to be moved.
Projects will be reviewed by project priority (most hours allocated in the sprint, close to launch, etc.).
Developers should inspect their tickets in advance in order to bring up any questions or concerns they might have. But additionally, during the sprint planning meeting, user stories should be opened and reviewed by the Scrum master (or whoever is running the meeting).
- Go through tickets by project or by person
- This is to ensure that developers are all talking about the same subject, and if anyone has any input, they can offer it
- ==Ask developer-assign if time is sufficient==
- If not, adjustments may need to be made
- Ensure task is clear and understood
- Ensure developer has entered their confidence levels and any medium or low confidence tickets are discussed and clarified. Confidence level refers to the developer's confidence in completing the task within time they've estimated.
- Ensure all developers have a fair allocation
- Over-allocation should not be allowed after sprint planning is over
Mid-Sprint Reviews
Currently these are completed during one of the PM Daily Standup Calls toward the middle of the Sprint.
The emphasis on mid-sprint reviews is to ensure no blocked tasks are still allocated into the sprint (no blocked tickets should be assigned at the beginning of sprint and these blockers should come from developers starting to work on tasks and need more clarification or other tasks completed to perform). If a task is still blocked halfway thru the sprint, ensure it has been looked into and determine if it can be replaced with a workable ticket from same project or if you can offer time to other PM’s.
- Ensure that blocked tickets are moved out if they are not going to be unblocked this sprint
- Replace the blocked tickets with actionable items
- Ensure no unparented or unassigned tasks exist
- Ensure no developer outside the pod for sprint planning is included
- Ensure developer tickets are not assigned to PM
- Ensure you have time associated for meetings, deployments and minimize bucket tickets
- This should occur regularly by PM throughout the sprint
- Be sure to check burndown daily and note if any developer is falling behind
- If developer is falling behind, work with them to get caught up
- This can also include moving out blocked tasks to get the developer actionable work
- If additional work has been added to the developer's sprint, it should be the PM adding that finds tasks to sacrifice to ensure that developers aren't overloaded
- If developer is falling behind, work with them to get caught up
Related Articles:
==Story Points Sprint Planning==== DevOps==