What’s the What?

I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:

Team,

I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:

Always ask yourself, “what’s the what?”

Always ask yourself, “why?”

As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.

The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.

Cheers!

Alec

Shadow Backlog

ShadowBacklog

The team was under pressure to deliver a rewrite of the flagship product after having been handed an agressive delivery date. In spite of the Scrum board and other information radiators in their area, the Scrum Master had to deliver progress reports to the CEO every day. The company president and vice presidents attended sprint reviews and grilled the team whenever a story was not closed or sprint goal not met.

One could easily argue that a fixed scope and fixed delivery date is in no way agile – end of discussion – but this still happens in organizations that use (at least partially) agile practices leaving Scrum Masters to navigate choppy waters.

Of course the team developed some coping mechanisms, the most insidious of which was kicking the can down the road.

Whenever the team encountered unexpected complexity or scenarios when working on a story, they said “this wasn’t in the story that we planned, so let’s call the current story done so that our sprint metrics will look good and handle the extra stuff sometime later.” Everyone except for the Scrum Master was happy – for awhile. Team velocities looked good. Stories were being closed as planned. On the surface it looked like features were being completed. The teams were going to deliver on schedule. The Scrum Master knew deep down that they were either going to deliver late or deliver an application with enormous amounts of technical debt. She also knew that the organization could not handle to truth so she soldiered on.

Then the bubble burst. The collective “oh crap” moment happened when people realized that the system should be production-ready but was not. Some features were incomplete. Bugs were still there from parallel testing that had been performed months ago. There was no room in the time before the expected completion date to resolve all of the open issues. Market launch would be delayed.

The ‘shadow backlog’ existed in the developers’ minds and in the list of open defects that were logged elsewhere from ongoing user testing. There were no product backlog items for them and no sprints in the release plan for addressing them.

Reflections:
– Make sure that all remaining work is visible. Create backlog items for stories, technical debt, and bugs. The backlog consists of Product Backlog Items (PBIs), not just user stories.
– Get user feedback during the sprint to avoid surprises later. Ideally users are integrated into the process via acceptance test driven development (ATDD). At a minimum they have an opportunity to see stories in action and provide feedback in the sprint. Any feedback and new ideas that cannot be incorporated during the sprint should be captured as real backlog items and sized/prioritized.
– Don’t be afraid to keep a story open if it was more difficult or took longer than expected when sprint planning was originally done. Better to take a little heat now rather than have the bubble burst later.
– Avoid ‘bucket stories’ near the end of a release that become a dumping ground for stuff that did not get completed in the sprints. Bucket stories can quickly grow exponentially and delay the release.

Backlog Grooming: Scrum’s Red Headed Stepchild

Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.

What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.

Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.

Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.

How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.

For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.

Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.

What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.

A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.

The PO typically runs the grooming meeting.

What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.

What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.

Reflections

  • Backlog grooming is an essential activity. Resist the temptation to skip it.
  • Schedule grooming meetings so that they fit In the middle of the weeks of the sprint.
  • The entire team should be involved in grooming.
  • Regular backlog grooming helps the PO establish a cadence for working on stories.

The Heartbeat of an Agile Team

What is the one focal point that catches every team member’s attention at the same time every day?  Of course it is their Scrum board. Some teams go through the motions and use their Scrum board because they are told to; for effective teams the board is a way to collaborate, manage work in process, keep track of impediments and know whether or not they are going to meet the sprint goal. Effective teams turn their board into a highly-visible collection of critical information about their effort. It becomes the heartbeat of the team and helps set the cadence for each sprint.

Their board might look something like this:

Board

 

Sprint Dates and Goal – as a reminder of the goal and the timeline. Seeing the sprint dates can be helpful if users who will be testing attend the standups so that they understand the sprint timing.

Columns for each step in their development process – This can be as simple or as complex as the team wants – it usually evolves as the team learns and tweaks its process to ensure a smooth flow of stories. In the example above, the team experienced issues with too many stories waiting for user testing. They created a column to show which stories are ready for user testing to make it clear to users when something is ready for them to test. During standups, the Scrum Master points out any columns where an excessive number of stories are piling up. Even with Scrum, the team may set limits for how many stories may accumulate in each column before team members swarm to address a bottleneck.

Sprint Calendar – during sprint planning the team members estimate on which days of the sprint they think stories will be Done and also when they will likely reach any other significant milestones in the team’s process such as being ready for user testing. This is a way of performing a sanity check for the sprint plan.  It is also a way for the team to gauge whether or not it is on track during the sprint. When user testing is part of the Definition of Done, it allows the users to plan when they will be performing this testing. Putting team members’ planned vacation days on this calendar avoids surprises in the middle of the sprint. It can also help to put key SME’s or users’ vacation days on the calendar if these could impact the sprint.

Impediments – unresolved impediments. Making these visible is a way to track them and may have the side benefit of prompting outside stakeholders who attend the standup or visit with the team to help the Scrum Master by finding other ways to resolve them.

Additional Stories – these are stories at the top of the Product Backlog that are ready to be brought into a sprint but that are not part of the current Sprint Backlog. These are posted on the board so that they are readily available in case the team reaches the sprint goal early and can complete some additional stories in this sprint. Note that these are not called “Stretch Goals”. That term can be perceived negatively by the team, almost as if they are not pushing hard enough in the first place to meet the sprint goal.

Release Burnup – the bigger picture of what the team is working towards. This help avoid the sense of being in an endless churn of sprints with no end in sight.

For teams using Kanban, many elements on this board still apply but may need slight modification. Note the use of colors throughout the board.  It is amazing how teams will adopt color schemes or symbols that communicate the state of their work, highlight important events, serve as key reminders, etc. One type of information not included on the example above is an area for Technical Debt.  Creating an open area on the board for this invites the team members to note it as soon as it becomes apparent to them.  These notes can then be translated into backlog items during grooming. This encourages open discussion about technical debt and surfaces this information rather than just having it in the team members’ heads.

A note for teams that use online/electronic Scrum or Kanban boards: additional information such as the PTO calendar, Impediments and release burnup can be captured in story cards and placed in a column dedicated to that background information. The sprint calendar can be captured by putting Due Dates on each electronic story card. On a physical or electronic board, the story cards can contain as much information as the team finds helpful. Typically the story number, title, and number of story points are included.

Reflections:

  • The Scrum or Kanban board can be used to communicate much more than just the status of the stories and tasks.
  • The information on this board should reflect each team’s personality and process. It will evolve as the team learns.
  • The Scrum Master can help the team during the standup by directing their attention to potential trouble spots on the board.

Does Agile Make Business Analysts Obsolete?

One of the most challenging aspects of adopting agile is requirements gathering and definition. The challenge is not because agile has complex methods for describing requirements, rather quite the opposite. Agile methods such as writing a user story on an index card and then relying on conversations between developers, product owners, and users to carry the story through construction might work for simple systems but breaks down when the domain or requirements are complex.

Product owners typically take center stage in driving requirements definition. These product owners, many of whom come from business units (rather than IT), cobble together various methods for capturing and communicating requirements. This is done without the benefit of understanding the difference between structured, object-oriented, test scenario-based, or other industry-standard requirements methodologies and why those methodologies came to exist. At scale, user stories on index card approaches break down, leaving team members and businesses as collateral damage.  Please do not misinterpret this as Product Owner bashing – developers are just as susceptible to thinking that they can handle complex problems without the benefit of structure.

Enter the Business Analyst. When a team is responsible for solving a large, complex problem, the business analyst works with the users, product owners and developers to root out key information. For applications through which there are significant data flows, this could mean creating (gasp!) data flow diagrams. For a highly-interactive, event-based system, this could be use case models or sequence diagrams.  A good Business Analyst possesses a skill set that many developers and product owners lack: the ability to understand the complexity of requirements and the best way to capture them.

One trap to avoid is to have the Business Analyst become the conduit (a.k.a. bottleneck) through which all communication between the users and developers occurs. This collaboration continues to be important and valuable, and the Business Analyst is involved to ensure important details are surfaced and consistent with the overall application.

Reflections:

  • A formal Business Analyst skillset is probably not  necessary for simple applications.
  • For complex applications, the Business Analyst plays a key role in ensuring that the right software is built.

Who Should Write UATCs?

Collaboration

Experienced agile practitioners take for granted that detailed requirements are captured as user test cases. For organizations transitioning to agile, this is one of the more challenging practices for them to adopt. Some product owners or business analysts still view the traditional “requirements document” as the way to capture detailed requirements. Because of their attachment to this traditional form of documentation, many resist replacing them entirely with User Acceptance Test Cases (UATCs).  They view UATCs as additional work on top of writing their traditional requirements.

UATCs better convey a sense of how the system is supposed to work by using examples rather than abstract, ambiguous business rules. In a mature agile organization, the end users are best qualified to write the UATCs.  This underscores the product owner’s role: they do not need to gather every detailed requirement – their job is to connect the development team with subject matter experts rather than being a conduit between the two.

Working Software over Comprehensive Documentation

Taken to the extreme, only the highest-level details are written down. This can work for small, simple applications. For large, complex applications, this is insufficient and quickly leads to chaos, disappointment, and frustration. The key is not avoiding writing down requirements, it is capturing them ONCE so that they can be used by product owners, developers, users, and testers and be the one living artifact besides the software.

What options do teams have for adopting the practice of capturing requirements as test cases?

1)      Developers write UATCs – while some might consider this sacrilege, in reality this is a great way to get started with UATCs and establish collaborative bonds between the development team and the end users.  Of course the developers’ initial version of these will usually only reflect what is in the acceptance criteria and what was discussed during grooming, but it provides structure for gathering more details from the users.  Users quickly see the value in this approach because the requirements are written in terms that they can understand – system behaviors. They also see the value in working directly with the developers. Product owners like this because it does not add to their workload and they quickly realize the benefits of the enhanced collaboration. One caveat: developers may need coaching about expressing things as tests and expected results since they may also be accustomed to thinking in terms of catch-all business rules rather than tests.

2)      Developers and users write UATCs together – given some starting point such as a sketch of a web page, the developers and users talk through the expected behaviors for a user story. This feels time-consuming but it directly involves the users in the process of devising the test cases.

3)      Users write UATCs – while this is UATC nirvana, it is important to remember that the developers and users still need to review the UATCs together and in detail. The test cases and end product always benefit from each group’s experience and perspective.

4)      Users and testers write automated UATCs – for applications that are able to leverage automated end user testing tools like Fitnesse, users will likely need assistance with the testing toolset, format, etc.

Reflections:

Be pragmatic about who writes the UATCs. Remember the goal: collaboration that leads to deep understanding of expected system behavior.

Normalizing Story Points Across Teams

normalized story points

On a large-scale agile project/program with multiple Scrum teams working toward the same overall goal, having user stories sized in a way that makes it easier to re-assign them from one Scrum team to another provides provides a planning and execution advantage when balancing work across teams to optimize delivery dates.

 

Before adopting a common story points scale, there are a couple of keys to consider in designing the team structures:

  • Skill sets should be balanced across teams rather than having teams that are specialized (i.e. don’t have a user interface team, a database team, a services team, etc.). This allows each team to develop entire features rather than individual layers of the application. And just as importantly, it provides flexibility to move user stories from one team’s backlog to another’s, helping to avoid any one team from becoming the critical path.
  • Once the teams are formed, the teams are kept together rather than constantly re-assigning people to different teams. The philosophy of “taking the work to the team” helps high-performing teams to continue to produce rather than paying the price associated with forming/storming/norming/etc. every time new team members are added to a team. This can be a very difficult concept for organizations that are accustomed to traditional resource leveling across a department or organization, but it critical to keeping teams operating at peak productivity.

With the team structure in place, features to be developed can then be introduced into each team’s backlog. On a project that is not constrained by a minimum feature set and go-live date (the kind that we read about in text books), the product increment is released when each team completes the features in their backlog and necessary integration/regression testing is complete. When a feature set is needed by a certain date, the project manager will seek to understand if one of the teams is on the critical path and not able to meet the forecasted code complete date. If this is the case, they may need to move some of the features or stories to another team’s backlog. In order to do this, the features and stories need to be sized in a currency that is common across all teams – story points.

On a small, single-team project, each team would be free to define what a story point means to them. On a large-scale project/program, it is important that the story points scale is the same for each team in order to facilitate balancing work across teams. This can be accomplished by identifying stories in the backlog that are representative of each story point size and making those stories known to all of the teams. Team leads then attend other teams’ backlog grooming sessions (especially in the early going) to ensure teams to not deviate from the standard.

Reflections:

  • Features and stories belong to the overall project/program, not to an individual team.
  • Sizing stories using a common story points scale makes it easier to balance work across teams.
  • Sizing stories using a common story points scale allows for consistency in project reporting such as team-level burndowns or overall project/program