GSD Gold Approach to the Agile Scrum Sprint
Before we talk about managing the work in your Sprint Backlog, we’ve got a couple of new agile mindset concepts for you to get your head around: the benefit of small batches, pair programming and shared responsibility to testing.
Benefit of Small Batches
It may seem counterintuitive that starting and completing one Story at a time from beginning to closure is more efficient than every developer on the team opening their own Story at the start of the sprint. In much the same way lean manufacturers like Toyota discovered that small batches made their factories more efficient, small batches help ensure Stories consistently close throughout the sprint (which gives you a better Burn Down, but we’re getting ahead of ourselves) and that the maximum number of Stories complete.
Why is this true? Mainly because there is less work in progress (WIP) and more completed goods (Stories). Plus, with synergy, two developers may be able to complete a Story more than twice as fast as a single developer. This leads into our second concept: pair programming.
Pair Programming
The formal definition of pair programming has 2 developers work together at the same workstation, with one developer programming or driving and the other programmer navigating or focusing on overall design and direction. The 2 developers can switch roles. The benefit of pair programming is higher quality code and shared knowledge.
In real life, we don’t expect 2 developers to share the same workstation. But in the spirit of getting stuff done and keeping minimum WIP, we suggest the 2 developers share a Story, divide and conquer. For instance, if they have questions about detailed requirements, one developer can begin coding automated tests and design the requirements they know about and the other can meet with the Product Owner or BSA. There are lots of creative ways to work together and get more stuff done. Experiment and become more efficient.
GSD Gold Shared Test Mindset
GSD Gold Teams produce quality products, because they take a 3-pronged approach to testing:
- Test driven development
- Write QA tests when the Story is picked up
- It’s everyone’s responsibility to test
GSD Gold Teams are committed to automated testing. In programming, there is the iterative concept of Test Driven Development (TDD), which is basically writing a failing automated test first, then writing the code so the test passes.
In GSD agile, we recommend getting the Quality Assurance testers immediately involved when the Story is picked up for development. Early involvement by QA, writing test cases based on the acceptance criteria, avoids having those resources sitting around for half the sprint waiting to test.
Agile scrum holds the entire team responsible for completing the Story. That means testing is everyone’s responsibility. If Stories get backed up waiting for QA to test, other members of the team must pick up the slack to get all stuff done on time.
Standup
The daily Standup or Scrum meeting should literally occur while everyone is standing up. That way, it keeps the meeting length to within the standard 15 minutes. Even if the team cannot be together in the same room, the intent of the meeting should be practiced. Standup should be scheduled for the same time every business day. Attendance is mandatory.
The purpose of Standup is to ensure the team is making progress, finishing Tasks and closing Stories. The focus is on the Story, not the individual developer or Task. The team starts with the first active Story on the board and discussion moves down the Story list until all active stories are discussed.
The Scrum Master’s job is to verify that progress is made on each active Story, table issues that need to be discussed outside the meeting and to identify blockers. If a topic was tabled, specific team members are assigned to meet after the meeting and report back the next day. If a Story is blocked, it is the Scrum Master’s responsibility to help the Story become unblocked.
If the team is co-located, we recommend the team maintain a manual Story Board somewhere in the shared workspace. The agile project management package you purchased also has an automated scrum board.
A manually maintained Story Board looks like this:
At the beginning of the sprint, The Product Owner lists the Stories on the left side of the Story Board from highest priority to lowest priority. The team identifies the Tasks required to complete the Story, writes them on sticky notes and posts them in the To Do (not started) column.
When a Story is selected to work on, a team member moves the first Task to the In Progress (active) column along the same row as the Story. When that Task is finished, the Task moves to the Done column. The process continues with the next Task until all Tasks are complete. When Quality Assurance and the Product Owner agree that the Story meets Definition of Done, the Story card itself moves to the Done column. By the end of the Sprint, all Stories should be in the Done column.
More than 1 Task can be active if multiple team members are working on it or if an activity is blocked. If you use a manual Story Board, reuse of Task sticky notes helps the team conserve paper.
For a better understanding about Story status, the team should standardize on Task names. That way, anyone looking at the Story Board understands the status.
Common Tasks include:
- Story understood (Does the developer truly understand the requirement? If not, meet with the BSA or Product Owner.)
- QA Test Plan
- Analysis
- Design
- Specification
- Code
- QA Test
As you better understand how the Story Board works, you can see how the benefit of small batches comes into play.
Burn Down Chart
The Burn Down Chart is a graphical representation of open Story points remaining in the sprint. On the left axis of the chart are Story points; across the bottom axis are number of days in the sprint. The chart defaults to a perfect 45 degree angle starting on the left axis at the number of Story points the team committed to in the sprint and ending at zero on the last day of the sprint.
Let’s use our 32 points example. On Day 0, the team has 32 points remaining. If no Stories close on the 1st day, the line moves horizontally to the right to Day 1, still at 32 points. On the 2nd day, if the team closes a 1 point Story, the line moves down to the right at 31 points and stops at Day 2. If no stories close on Day 3, the line stays at 31 points over to Day 3. Each day of the sprint, the graph updates, based on whether or not Stories close.
It’s impossible to achieve a perfect 45 degree angle, but you do want to see progress in that direction. What you don’t want to see is a cliff, where the line goes mostly horizontal at the same level until the end of the sprint, when most of the stories close. Again, you can see the benefit of small batches help achieve smooth burn down.
Here’s what an automated Burn Down chart looks like when the team went off the cliff at the end of a sprint:
Most of the stories were removed either completed at the end of the sprint or removed to the Backlog.
For comparison, here’s the same team’s Burn Down in the middle of a later sprint that looks more like the 45 degree angle that we want to see:
Every agile project management package automatically produces Burn Down charts for you. If you team is co-located, get a large sheet of paper and manually track burn down every day. This can be a powerful motivator to more quickly close Stories. Regardless of location, celebrate every time a story closes and brings you closer to your sprint goals.
GSD Gold Approach to Scrum of Scrums
We know that in the corporate world, scrum teams don’t have the luxury of working in a vacuum. As much as we don’t like dependencies, we admit that in the real world, agile projects often depend on the work of more than one team.
In Chapter 3, we talked about independent Story writing. Yes, stories are independent, but fully functional applications may depend on the work of multiple teams.
Agile scrum has an optional weekly meeting called the Scrum of Scrums. Since we are not big fans of meetings, Scrum of Scrum meetings should only be utilized by large projects with over 3 scrum teams. In the traditional world, cross-department project meetings are often run by the PMO, program manager or project manager. The Scrum of Scrums may also be the responsibility of these same individuals.
Like program and project meetings, the goal of the Scrum of Scrums is to meet a shared release milestone, resolve issues and share knowledge.
However, the Scrum of Scrums is NOT a giant daily standup or project status meeting. The only purpose of the Scrum of Scrums is cross-team dependencies. These meetings ensure all the teams involved with the project resolve cross-team issues and bring in the right Stories at the right time.
With 2 week sprints, there should be a Scrum of Scrums the day after sprint planning and halfway through the sprint. Keep the meeting to a half hour, short and sweet.
Topics include:
- Unresolved issues that require the expertise of another team.
- Did the teams bring in the right dependent Stories to keep the release on track?
- Status or big reveals uncovered when working on dependent Stories.
- What dependent Stories must be worked on next sprint?
< Back to Chapter 5 Sprint Planning —– Chapter 7 Continuous Improvement
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.