Agile Sprint Planning and Development

 

Sprint Planning

Sprint Planning is one of the most exciting parts of any Sprint. It's an opportunity to imagine and explore the needs of the customers and stakeholders. Everyone is involved and the Development Team really gets ask all the detailed burning questions needed about the requirements they're preparing to implement.

The key steps in this process include:

• The Product Owner presents the Updated Product Backlog
• The Development Team selects User Stories for a Product Increment
• The Development Team refines User Stories enough to estimate and finalize selection

In completing this process, there are couple of key tenants:

• All voices need to be heard
• Everyone has to agree on the Sprint Backlog
• You need to get all planning completed quickly! 

How would you quickly get all of this accomplished to plan work for two weeks or four weeks?  Think of all the points of discussion on one User Story, let alone a team's worth! 

Sprint Planning Summary Points

Sprint Planning has three key objectives:

• Product Owner presents the updated Product Backlog
• Development Team selects and refines User Stories
• Development Team is able to commit to the Sprint Backlog

However, to ensure the authenticity of those objectives are met the following must happen:

• All voices must be heard
• Team must review and elaborate all User Stories in the Sprint
• The Team must be able to size and select those stores within the timebox of the Sprint Planning!

The "timebox" for sprint planning is usually half a day for a two-week sprint, or a full day for a four week sprint. The same applies for Team Retro and Reviews. This allows for one day out of two weeks (1:9) ratio to be spent on planning and review.

To do this correctly, the team must avoid:

• Getting into long, drawn-out discussions on requirements
• Conflicts that can destablize the planning meeting
• Not having the information needed to plan

The key to making a good Sprint Planning Work is two-fold:

• Great User Story writing by the Product Owner (and/or Development Team in variations of Scrum)
• Planning Games

Great User-Story writing means that the Scrum Master and Product Owner need to work together to ensure User Story quality. This is especially important when the team has a new Product Owner, who hasn't worked on a Scrum team or THIS Scrum team. Story writing is extremely cultural.

The use of Planning Games is essential because it helps to facilitate and elicit creativity from the team. Often this is when many teams will ask, "why not just talk about the stories?" The key reasons for NOT using unfacilitated discussion or "open discussion" is that it's NOT open:

• Loudest voice in the room wins
• There's no timebox or time limit on discussions
• There's no way to tell when consensus is reached
• There's no way to improve without structure to improve upon

For this reason we use games in Scrum. The most common is the Planning Poker Game.

Planning Poker Game. Key source for these rules is: http://agileinaflash.blogspot.com/2009/07/planning-poker-r.html

• Agree on a point scale
• Team briefly discusses the User Story
• Everyone picks a card in silence
• Team members reveal the card
• If an outlier exists (more than one step from the mode), then discuss
• (Optional) After two rounds take an average, and validate with a "yes/no" team vote

This process is used to accomplish three things:

1. Validate that the size of the story is correct
2. Validate that the User Story is well understood
3. Ensure all voices are heard equally when disagreements occur

Many times there are disagreements about how to develop a point scale. There are valid reasons, especially when Story Points are misused by team members or management outside the team. Here are some key points to consider:

• Points are a relative metric
• Points should consider more than effort
• Complexity - how hard is it?
• Uncertainty - how certain are we know the business reqs and potential technical solution?
• Effort - how much total work?
• Points should be consistent across Sprints, but not necessarily across teams

Please note that many types of "Scaling Frameworks" disagree, with basis, on whether User Story points should be an absolute metric, or at least shared across multiple teams. For Scrum and it's variations this is not important. Story points are solely to help the team know how much work can be accomplished and if the team is getting faster Sprint after Sprint.

We continue to explore these concepts of how to use scaling of points and measurements of team performance in the Agile for Control course in the Agile Project Management Curriculum. As well as briefly in next week's lessons on Scaling Frameworks.

Finally there are few additional items to consider for Planning:

• Work iteratively through picking Stories prior to Sprint Planning
• Select Stories that combine to form a cohesive "Product Increment"
• It's best if the Product Owner has something in mind already
• This Product Increment should be written down as a "Sprint Objective" to help focus Planning
• Work one-by-one through User Stories when performing the Planning Poker game
• This is fastest, because everyone is focused on the same story at the same time
• This is easiest because you only have to think about one story at a time
• Make sure to leave a little buffer on your first Sprint
• Make sure that everyone commits to getting the work done - don't let everyone leave without a clear "confidence" vote from the team
• You will end up refining the Product Backlog and identifying potential dependencies in this process - that's okay!
• When updating the Sprint and Product Backlogs - do it now. Don't lose those moments of insight that come in planning
• Make sure that the tools you use are simple and effective to make this go smoothly
• Finally, be sure to prioritize the Sprint Backlog so the Development Team knows which User Stories to start on first the next day.

By following these guidelines your planning will be faster, more inclusive, and more accurate than any group discussion or interview process could hope to achieve.

Sprint Development

Sprint Development is upon the team. It's the first day and a Sprint Backlog of User Stories fresh in mind awaits the team. Time to Stand Up and start delivering!

Sprint Development is much different than the type of work experienced in Traditional environments. Every morning the team meets, rain or shine, good day or bad day, and they discuss the work-in-progress. To ensure that no team member is stuck many tools are used, some of which we've discussed briefly already:

• Daily Standups
• Kanban or Scumban boards
• User Stories
• Face-to-Face meetings
• Focused time at your desk! (Imagine it!)

The goal of these tools is to reduce the time spent in meetings to the essential. Teams will open up less work than the whole team could work on concurrently as individuals. Why? Because that way when someone needs help there are people to help. Everyone isn't "too busy" to jump in and solve problems together. 

Also, there is no "i" in team, and the "m" and "e" are always preceded my "t" for team. The team comes first because the whole team is evaluated on performance together, and no one person "owns" the work. Team ownership means everyone has a shared interest: completing the Sprint Backlog.

Imagine removing all "coordination" meetings with a five-minute standup. Imagine having help whenever you ask for it. Imagine getting work done during the day

Sprint Development Summary Points

To begin, it's important to review the principles of Sprint Development:

• Daily Stand Ups - daily face to face communication so there's no "scheduling" of coordination
• Whole Teams - Everyone knows what the work is (we planned it together), and works on it together
• Team Ownership - Multiple team members working on the same User Story
• Limit WIP - limit the Work-In-Progress (WIP) to achieve faster, predictable development with focused time

When we look at these principles we see a lot of the Agile Manifesto Values restated within them. 

• Individuals and Interactions over Processes and Tools Daily 
• Working Software (Systems) over Comprehensive Documentation        
• Customer Collaboration over Contract Negotiation                       
• Responding to Change over Following a Plan                                    

Daily Stand Ups

• Two types of daily standups
• "Scrum Standup" - each team member reports on what they did, what they plan to do, and any blockers
• "Forward-Looking Standup" - facilitator asks about work-in-progress, team self selects what they'll be doing

Whole Teams

• Whole team is available to work on closing User Stories
• Product Owner provides input on features as developed, and is available to close stories
• Scrum Master facilitates meetings, workshops, and ensures quality through good User Stories, Story Closing, etc.
• Development Team collaborates to complete work, which may mean switching to help others
• Continuous Planning
• As product takes shape, Product Owner consults with stakeholders to gather feedback
• Scrum Master ensures feedback is facilitated and efficient
• Scrum Master works to engage other stakeholders as necessary, or other teams at scale
• Product Owner write stories, which are audited by the Scrum Master

Team Ownership

• Teams know what work needs to get done, each supporting as needed
• Sometimes that means three Development Team Members work on one User Story
• First gathers user interface (UI) and process requirements from stakeholders, and builds UI
• Second begins working on technical solution for middle (logic layer) and backend (data management)
• Third designs and builds tests based on Acceptance Criteria (automated tests)
• Scrum Master might facilitate meetings with stakeholders or UI rapid prototyping
• Product Owner will validate the final product
• If one User Story begins to fall behind, then pair programming or "war rooms" can be established to solve the problem
• Team members know the work, and can jump in to help
• No individual ownership removes issues of "pride of authorship"
• Team reduces risk of failing to deliver critical functionality
• This "Team Ownership" ensures progress on the highest priority work, which also carries the most value for stakeholders

Limit WIP

• Limiting work-in-progress (WIP) enables all processes to work faster
• Reducing WIP means team members are available to support as needed
• Reducing WIP means fewer meetings and coordination activities
• Reducing WIP means clear, small tasks that can be accomplished and reviewed quickly
• Reducing WIP means more time spent getting work done, and less time organizing multiple acitvities
• Primary means of reducing WIP is to use a Kanban or "Scrumban" board
• Kanban board - manages stories as work items, moving Stories across the value stream of a states
• Stories may have three or more states, often requiring five states (Planned, Ready, In-Development, Testing, Done)
• Each state is limited in terms of the number of stories allowed (such as only two in Testing at once)
• Limiting the WIP in each state ensures that work must be completed before starting new work
• Scrumban Board - manages tasks as work items, moving tasks and then Stories across a value stream of states
• Like Kanban, there are three or more states that tasks and Stories can be in, often five (Planned, Ready, In-Dev, Testing, Done)
• Stories can only move forward in states in the Value Stream once all tasks have moved forward
• Stories are only "In-Development" if all tasks are "In-Development" or further in the Value Stream (e.g. "Testing")
• Stories and tasks are managed in their own row or lane
• Scrumban may also include "fast lanes" for high-priority tasks

Note that many of these techniques are borrowed from Lean approaches; especially the Kanban board for limiting WIP. This is because once Stories are planned the team should operate like a well-oiled machine cranking through work. The goals of continuous improvement and reducing waste definitely apply. 

However, one key aspect of Scrum that differs and remains Agile is the fact that the Product Owner is on the team, and they can accept work incrementally. Also with the full transparency of the Sprint Backlog showing what work the team must accomplish by the end of the Sprint, the Development team can decide to manage their time based on those Sprint Requirements. These Stories also combine to form a meaningful, shippable increment.

For these reasons, Agile offers sustainability, purpose, mastery, and autonomy to the Development Team not offered in pure Lean approaches. These elements have been proven to be the most motivating for teams of knowledge workers.