I have been developing a product which focuses on solving Agile Product Development Challenges and helping software development teams achieve their goals and milestones on time. Starting with that vision, I read about many case studies how teams implement Agile, how they work, how they plan to scale, what tools they use, what they want to use, why they want to use a tool and what are the challenges.
Taking feedback from teams that used our product as alpha testers, I found that each team/ company/ individual works in his own way and has his own approach. Out of 10 only 8 would know why Agile came into picture; rest who would have done the certifications and have read about Agile in depth would force it in a manner that it would become difficult for a layman to understand. So Is it effective Agile Implementation?
I personally believe there needs to be a balance. To implement or practice Agile well, one needs to understand why is he transitioning to Agile and what is the problem he is trying to solve. For example, if written daily stand up has to be time boxed to 15 minutes it does not mean you end it up after 15 minutes if there are critical issues to be addressed; that should be done and there has to be a solution at the end, in this case, goal is to understand WHY STAND UP?
Similarly, If we are doing sprint planning , we need to understand the velocity and plan well. We should understand “WHY SPRINT PLANNING?”
Sprint Planning gives the team
- A destination or goal which makes their journey worthwhile
- An opportunity to be included in the decision making
An effective planning needs the right ingredients to start with and needs a lot of preparation:
- Product Backlog – A prioritized, refined and well maintained backlog with tasks broken down into workable modules.
- Velocity – Calculated based on the team’s velocity for last three sprints.
- Current status of the product
- Business Constraints
The meeting is the next part which basically has to answer two questions:
- What? – This is where product owner communicates the requirements in detail to the scrum team.
- How? – The team discusses how they are going to deliver it.
Some Do’s & Don’ts for Sprint Planning:
- PO has to trust the team & maintain a motivated environment.
- Scrum master must ensure participation of all members.
- PO should not be making all the decisions, everyone should contribute.
- There has to be a consensus on the method of estimation and work breakdown i.e. planning poker or story points.
- PO, SM, developers, testers, DBA – anyone who is part of the development team should be there. Stakeholders can attend only in an observatory capacity and cannot interrupt.
- It should have a set starting time.
- Length of the meeting depends on length of the sprint. As a general guideline:
- One-week sprint – 2 hours
- Two-week sprint – 4 hours
- One-month sprint – 8 hours
It is a time boxed meeting. End it on time. It is OK to not know all the details it promotes agility.
- Establish the “Definition of Done”.
- Define a high level agenda & structure of the meeting. For example: PO speaks first, team discusses the items together, Q&A with PO, sprint backlog refined, retrospective & meeting close.
- Keep the focus on the goal and define a succinct Sprint backlog. Allow your sprint backlog to evolve and refine itself during the sprint.
If we just understand why Agile was brought into picture, what problems need to be solved, map those to our current scenarios and plan accordingly, we should be able to achieve our goals in an agile manner.
Stay Agile !