Author: Alec Hardy

User Stories – What’s in a Name?

Alec Hardy Requirements

The team was eager to launch into their first release planning exercise.  Wisely, the Scrum Master and Product Owner (PO) did not hand the team a list of already-written user stories.  They knew that while it would take the team a little more time to identify and write the basics of each story, it would pay off many times over with the understanding and ownership of the stories created by this exercise.

The PO presented the first requirement. “Team, we need to provide the back office system with a summary of the day’s sales.”

A developer on the team eagerly grabbed a sticky note and jotted down the story.

OriginalStory

While the developer’s willingness to jump in and start writing a story is exactly what the PO or Scrum Master like to see, what is wrong here?  What should the PO and Scrum Master do in response to this story?

Part of the Product Owner’s job is to make sure the team understands WHO the feature is for, WHAT it is for and WHY it is needed. This is crucial because it allows the team to understand the vision for the feature, who it will benefit, and the value that it provides. This information can spur questions from the team and provide guidance as they weigh various potential solutions. Technical teams can very quickly jump to the HOW without fully understand WHAT they are building or WHY they are building it.

We all know the template for a user story: “As a <type of user> I want <some goal> so that <some reason>”.

Right away we can see that the story does not address who the story is for. As written, the story provides at best a modest sense of the goal, but with verbiage such as “Add task in scheduler to invoke C# application” it is more about the solution that the business goal.

Lastly, one of the most powerful components of a user story is the “so that” clause. This forces the PO to justify the story’s existence. What benefit will it provide?  How will it help achieve the overall vision?  If the PO can’t come up with a “so that” clause, there is a good chance that the story is not needed or is not well-enough understood.

Recognizing this, the Scrum Master jumps in and explains this to the Product Owner and the team members. The PO gives a more thorough explanation of the story, focusing on how it will help the business. The end result:

RewrittenStory

It may not be perfect yet, but it provides much more meaningful information than the original version.  This story will trigger valuable questions from and conversation with the team and ultimately lead to a better product.

Reflections:

  • If the story title is about the technical HOW and not the business WHAT, guide the team in rewriting it so that it reflects the business need or goal and not the technical solution.
  • Don’t overlook the “so that” part of the story. It forces the PO and team to justify the story and truly understand it.

The Heartbeat of an Agile Team

Alec Hardy Communication, Developer, Kanban, Scrum Master, Sprint Planning, User Stories , , , , , , , ,

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?

Alec Hardy Business Analysis, Requirements, User Stories , , , , ,

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.

Bring the Work to the Teams

Alec Hardy Portfolio Management, Scaling , , ,

WorkToTeamAs new high-priority features surface on a large program it can be tempting to give in to demands from stakeholders to assemble a team of the best people from the existing Scrum teams to build those features. Typically someone will suggest plucking the best people from the various Scrum teams and forming a task force. If anyone tries to talk you into doing this, don’t let them. In agile, restructuring the teams should be done sparingly and carefully. It takes a team of people several sprints (and sometimes months) to learn to work together effectively. Reorganized teams also represent change and the range of human factors that come with change. Large scale agile is about bringing the work to the teams, not assembling groups of people for each package of work that needs to be completed.

Another consideration when someone suggests putting together a task force is that it needs a Product Owner, Scrum Master and the various cross-functional roles such as BAs, QA, etc. to be covered. Gutting existing teams to staff these roles leaves the other teams in disarray. And, of course, we would never even consider sharing people across teams, would we?

The next time someone proposes a task force, take a look at how this work can be done by the teams already in place. Chances are pretty good that the work will be completed faster and better by the established teams.

Evolving Team Structures Through the Product Development Lifecycle

Alec Hardy Developer, Leadership, Portfolio Management, Product Owner, Scaling , , ,

One of the most fascinating management challenges is determining the best structure for Scrum teams based on the stage of the project. This does not mean the major waterfall phases like Analysis, Design, Construction, etc. When developing software for use by customers (especially niche SAAS products) and there is some level of customization or specific features for each client, there are at least a couple of distinct stages in the project:

  1. Develop the base product
  2. Develop client-specific features and convert those clients onto the system as those features are completed

Many agile writings suggest that the way to approach system development is to develop some features and put them in production right away so that clients can start using them immediately. In reality, this does not always work. For example, when an existing system is being replaced, clients cannot be put onto a new system that only has 20% of the functionality of the one being replaced. Of course, this does not preclude some form of testing of that 20% by users within the development organization (e.g. by internal client service reps who are also part of the user base).

Organizing for Base Product Development

Typically the base product development effort focuses on developing the major feature areas. The development teams can be organized along the lines of the features areas as depicted below.

Base Product Team

Organizing for Client Conversions and Onboarding

 As the base product nears completion and the teams start to work on client-specific features, the portfolio or program manager may start noticing that the client code complete date for one of the feature teams above is much later than the other teams because the bulk of the customization for that client falls on that one team. The net result is client on-boarding dates are further out in the future that delay realization of new revenue from the product. This is a clear sign that the team structures need to change. At this stage, the focus shifts to optimizing staff utilization while retaining the benefits of teams building features or feature slices from top to bottom. This is called Focused Balance. Work is focused as much as possible on one or a few teams to gain the efficiencies that come with understanding and ownership of the epic , but when necessary client-specific epics are spread across the teams to deliver them as soon as possible.

Client Onboarding Team

Restructuring the teams

When scheduling and work allocation issues require that multiple teams work on the same epic, the following should be considered when deciding who should be on each team:

  • Knowledge about specific feature areas of the system.
  • Technical skillsets. Rebalancing may be necessary when certain feature areas from the base development phase emphasized a particular technical skillset.
  • Technical leadership – most teams need a technical leader.

Cross-Training and Collaboration

Team members will need to step out of their comfort zones and learn other parts of the system. Product owners, who have become experts in the feature areas that their teams constructed in the initial stages of development, will be overseeing a backlog that contains features and stories that are outside of their current area of expertise. Recognizing and fostering the need for collaboration across the teams is critical to the success of this model. At this stage, the job of the product owner is to connect team members with subject matter experts rather than being the subject matter experts.

Reflections:

  • Team structure may need to change to optimize the schedule for client-specific feature development.
  • Restructuring and rebalancing evenly distributes system knowledge and technical skills across the teams.
  • The Product Owner’s role changes to be less of a subject matter expert for their team and more of a facilitator.

Who Should Write UATCs?

Alec Hardy Communication, Developer, Product Owner, User Acceptance Test Cases, User Stories , , , , , ,

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

Alec Hardy Sizing, Sprint Planning, Story Points, User Stories , , ,

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