The failure of the previous sprint is evident when the team’s calculated effort is not matched with the estimated effort. The team has spent 2 weeks to improve and add value to the product, but on the retrospective day, there exist a stark difference between sprint planning and its execution.
The developers have worked as in accordance to the sprint goal, but the actual value addition and velocity of the sprint is less than any of the previous sprint. The good news is, you can improve this from the very next sprint. The advantage of having 2 weeks sprint is, you can improve your planning after every 2 weeks and with proper execution, you can increase your velocity and add more value to the product.
Approaching Retrospective
During the retrospective, it is very important to understand the purpose of the meeting. The purpose should include but not limited to ‘Where we went right?’, ‘Where we went wrong?’, ‘Where should we improve?’, ‘How to approach the next sprint?’ etc. The parameters for retrospective are clear, but the important factor we need to check is the velocity of the sprint. The velocity of the current sprint should align with velocities of previous sprints. According to my understanding the general allowable increase or decrease in velocity for completed story points should be around 10-15 story points. This indicates the effort taken by the team is consistent throughout and there is neither decrease in target no additional burden on the team.
The retrospective also helps in analyzing an individuals performance. Any project has multiple team members, so performance in a team is an important factor that needs to be analyzed. Individual pace of work matters, but in a sprint the overall performance of the team is at stake which makes the value of being a team player more significant.
Sprint Planning Approach
Splitting the sprint timeline in parts and analyzing these parts standalone gives us interesting insights, in simple terms, this approach gives us details that we might miss and every such miss might affect the overall sprint goal. Ten working days in a sprint to be divided in 5 parts of 2 days each, the completed story points for 2 days should be estimated from the overall commitment planned. This approach gives us a minute detail of supposedly completed story points, and the developers also get the idea of the effort they need to put to complete the estimated commitment.
Changing the sprint goal in the midst of the sprint is a disaster. The goal is to be decided by the product manager and thereafter should be conveyed to the developer, client’s requirement and expectation from the current sprint should be the base to determine the sprint goal. Velocity of a sprint may be affected by various reasons, one, if the commitment increases than previous sprint but the actual completion remains the same, or if sprint goal changes due to client’s requirement in the midst of current sprint. The client’s priority, if not aligned with the sprint goal will prove to add no value to their product, which will affect the intangible asset of our company i.e., customer satisfaction.
Additionally, time required to resolve the bugs affects overall velocity of the sprint. Bugs have no story points as it arises from our previous commitments and it does not add any value to the product. The aim is to reserve our time to identify the effort and time required to resolve the bug and move forward towards value addition issues. If bugs takes more time than estimated, then option is to improve our estimation for the next sprint, because there can be hardly any changes made after we start the sprint. The time required for bugs is based on developers expertise and experience, but as a product manager we cannot completely deny our responsibility of adding value to the product in the current sprint as committed before the start of the sprint.
Learning from Mistakes
An important principle for any profession is to learn from previous mistakes, and this field is no exception. When a product manager cannot complete his commitments, the next sprint planning should be improved. If an estimation for a sprint is a miss, then as a team, we should improvise, adapt and learn so that we do not repeat the same mistake. If one day client’s requirement exceeds, then being grateful and politely saying ‘No’, along with explaining the reason and facts is also the duty of product manger.
Retrospective is a biggest tool to analyze, find gaps, identify mistakes and improve them for the next sprint. ‘Kaizen’, a Japanese term meaning ‘continuous improvement, is a Japanese business philosophy regarding the processes that continuously improve operations and involve all the employees. Similarly, retrospective helps in paving the way for continuous improvement and adding value in each sprint for the client.
Thank You!
