Getting Started with Story Points

A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past, but how does a new team that perhaps even has people who are new to agile get started with story points? As I mentioned in another blog post, Ideal Days is a story point estimation scale that blends size with effort and degrades the backlog sizing process into a drawn-out time estimation exercise. Given that a points scale like the Fibonacci sequence that relates more to size/complexity is preferred, how does a team get started when it does not have a baseline story against which to do relative sizing?

A few things should be in place to set the stage for establishing a baseline story:

  1. Definition of Done. This should include quality assurance and user testing.
  2. Sprint length. Should be no longer than two weeks.
  3. Understanding by the team that high throughput is achieved via low work in process, i.e. having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint.

Once there is a set of stories in the backlog that are small enough to pull into a sprint, the next step is to discuss and assign story points. In asking the team to assign story points for the first time, I usually tell them something like this:

Team, we know that in order to meet our sprint goals we need to get the first story in this sprint coded, unit tested, and into QA by the second or third day of the sprint. Let’s call that a three point story.

With that in mind, the team sizes the first few stories. Some might argue that we are just using Ideal Days. We are not, because executing and supporting the QA and user testing efforts are not included in the goal of getting the story to QA by the second or third day of the sprint. The other reason we are not using Ideal Days is because we only use this method for sizing the first couple of stories in the backlog. After that, all estimations are done relative to those first couple of stories that were sized, by asking whether or not a story feels bigger or smaller than those stories.

Reflections:

  •  Establish the Defintion of Done, sprint length, and concept of high throughput via low work in process before sizing stories.
  •  Size stories with the goal of getting the first story into QA within the first few days of the sprint.

Sprint Length – Does Size Matter?

RulerWhen a team that is accustomed to working on 6, 12, or 18-month long projects adopts agile practices, the prospect of planning its work every week or two is daunting. Planning the work every month might be tolerable so the team goes with four week long sprint lengths. As the team becomes more and more agile, the four week long sprints start to feel drawn out and constraining. This prompts the question, does sprint length really matter?

Smells that indicate a need for shorter sprint lengths

  1. Multiple teams on same program needing to re-sync/adjust frequently because of dependencies:

In a large program consisting of several feature teams, the work produced by one feature team often becomes an input into work done by another feature team.  For example, consider Team A and Team B. Their sprints are synchronized to begin and end at the same time to help with release planning and tracking. In any given sprint, Team A may produce something in the first part of their sprint that is needed by Team B in order to produce something else in the latter part of their month-long sprint. In theory this works, but in reality as soon as something delays Team A from delivering, Team B’s sprint commitment is jeopardized. After this happens once or twice, members of Team B will no longer be willing to commit to work with cross-team dependencies. One or two-week sprints eliminate many of those disconnects.  Team B simply does not pull an item into one of their sprints until Team A is done building the pre-requisite feature set. Because the sprint length is short, there is minimal delay between Team A finishing their feature and Team B starting their work.

Note: this does not presume that component teams (that only develop one layer of the app then hand it off to another team to develop another layer) are to blame here.  These interdependencies also occur with feature teams.

  1. Team sagging in middle of the sprint and then having a burst of energy towards end of sprint.

Teams using four week sprint lengths, in spite of the professionalism and motivation of team members, can be susceptible to waiting until a deadline looms to become focused on what is needed to close out stories. The effort and energy level may not really crank up until the latter part of the sprint. Have you ever worked with a Scrum team whose energy level looks something like the graph below over the course of a sprint?

Energy Level

This is a sign that the longer sprint length is causing the team to lose focus and/or momentum until the point when they need to “put the pedal to the metal” in order to meet the sprint objectives before the close of the sprint.

  1. Team taking on a small number of large stories.

New Scrum teams often have difficulty slicing features into multiple, smaller stories. Sometimes this is because the users are afraid that if they don’t cram all of their requirements into this one story right now then they will never have another opportunity to build the rest of the functionality. Without going into a dissertation about queuing theory (check out Little’s Law if you want more info about this), large stories have a profound (negative) impact on team throughput. One of the most tangible effects of large stories is that there may be little or nothing for the users to test until near the end of the sprint, which then results in a mad scramble to finish the stories. Not exactly a model for a sustainable pace and high quality.  Shorter sprints force teams to break large stories down into smaller pieces. Once they get the hang of it, they will size the stories so that they can deliver a steady stream of functionality to QA, the Product Owner, and users for testing throughout a sprint.

  1. Team is finding that the large number of small stories is getting hard to manage and wants to combine them into just a few large stories in each four week sprint.

For teams that become adept at breaking stories down into smaller stories, a new challenge can be that there are so many stories in a four week sprint that it becomes almost unmanageable. This is a clear signal that it is time to move to shorter sprints involving a lower number of but still small stories.

  1. Team is tinkering with what stories are in the sprint backlog due to learnings that occur early in the sprint.

What if, early in the sprint, the team learns something while working on a story that results in a new story being created that encompasses those learnings? While it is commendable that the scope of the current story was not just expanded, what is not so commendable is that often teams, especially ones working on four week sprints, become tempted to swap out another story lower in the sprint backlog for this new story because otherwise the team will not be able to address the new story for another month. Of course a constantly shifting sprint commitment is hazardous to a team’s health. A team working on two week long sprints would not need to be concerned about long delays before it can address the new story.

Nowhere to hide

Just as the initial agile adoption effort brought many organizational dysfunctions to light, shorter sprint lengths will unearth still more issues. Sporadic involvement of the product owner or users cannot be concealed in a two-week sprint. Excessive work in process, with a team that is hesitant to swarm on a small number of stories at one time, creates bottlenecks for testers, product owners and users who must focus on large number of conversations at once rather than focusing on a few at a time. Shorter sprint lengths will expose these and other shortcomings and allow a team to quickly learn and adjust its practices. Also, if the Scrum Master is wise enough know when he/she needs to let the team members fail in a sprint in order for them to learn a tough lesson on their own, the impact is muted due to the shorter sprint length.

Roadblocks

If the case for one or two week sprints is so obvious, why is it hard for some teams to adopt them? A common roadblock is stakeholder concern that more sprints will result in more “unproductive” time planning sprints, doing retrospectives, and conducting sprint reviews. The reality is that sprint planning time should correlate very closely to the number of stories in the sprint, therefore a shorter sprint = less time needed for planning. Retrospective and sprint review meetings can also be shortened accordingly.

Reflections

  • One or two week long sprints allow teams to better synchronize their efforts.
  • Small stories are that much more important with shorter sprint lengths.
  • Shorter sprints require more consistent involvement from everyone on the team, including testers and product owners.

Story Points or Ideal Days?

Fibonacci CardsSizing user stories is a key part of understanding the overall effort required to create a product release. Getting started is simple: pick a baseline story and assign a number of Story Points or Ideal Days that it will take to complete the story. Next, look at other stories in the backlog and decide whether or not they are bigger or smaller than the baseline story and by how much. Lather, rinse, repeat.

Developers coming from waterfall teams are accustomed to doing time-based estimates. Junior or intermediate level developers were usually asked to estimate functionality that was well-understood and broken down into small units of work. But in waterfall efforts, sizings done during project inception were probably done using a high-level estimation technique such as function points by a more senior analyst, lead and/or architect. Agile user stories are not necessarily well-defined or split into small stories the first time that they are sized (they will be by the time they are brought into a sprint plan). Because of this legacy of thinking in terms of hours to build, developers often revert to using a time-based estimation technique when trying to size user stories.

Before we go any further, some quick definitions:

Story points: a points scale (possibly using the Fibonacci sequence – 1,2,3,5,8,13,21,etc.) that indicates the size of a story relative to a baseline story.

Ideal days: the number of days of effort that it would take the team to get a story done if the team worked with no interruptions.

Once the team has sized the baseline story, it is ready to start comparing other stories to it and assigning points to them. But along the way, developers may develop an ‘algorithm’ for assigning Story Points. You know they have done this when one of them says, “I think that story will take 8 hours, so it’s a two-pointer.” What is happening is that the developer is doing a time estimate of their effort and reverse-engineering the story points rather than sizing the story relative to other stories. This is when the ScrumMaster needs to remind the team about the goal of sizing stories and why Story Points are a better approach than a time-based estimation approach.

Story Points are for sizing, not for time estimation. This allows teams to:

  1. Quickly size features and create a release plan without getting bogged down in implementation details. Team members are often very reluctant to provide time estimates unless they have all of the details about a feature. Being agile means that it is okay not to have all of the details up front. Developers typically are more comfortable saying that Feature B is twice as big as Feature A knowing that they won’t be held to a specific time estimate.
  2. Use Story Points in conjunction with the team’s velocity to make delivery date projections that are not as prone to decay as those using story-level time estimates. Relative sizings based on Story Points are usually fairly stable; estimates based on time can change dramatically as a project unfolds. In conjunction with Story Points, velocity is a reflection the team’s productivity and expertise. This is much easier and more flexible than trying to bake size, effort, productivity, and expertise into one ideal days number for each story.
  3. Create sizings that include all of the effort to get a story to ‘done’. Story Points include development hours, user interaction design, QA testing, etc.
  4. Prevent stakeholders from using Ideal Days estimates to calculate unrealistic delivery dates which are then mandated to the team. It is not their call how many hours per day the team spends actually working on user stories. They do not have a sense of how the mix of skills on the team or other factors will impact productivity. It is up to the team to determine how much time it can spend working on stories, and how much time it needs for grooming the backlog, doing production support, etc.

Reflections

  • The team should size the backlog without having deep, detailed requirements conversations.
  • Story Points are a way to size features without having to calculate how much time it will take to do the work.
  • Story Points are less prone to decay than Ideal Days.

Introducing Scrum to a Team

GoFor a Scrum Master introducing agile to a team, there is a balance between implementing concepts and practices at a pace that does not overwhelm the team and demonstrating the benefits as early as possible to build momentum and support within the organization.

Each situation is different, but let’s assume that an organization wants to use Scrum and there is an experienced Scrum Master who has been asked to lead a team of people that are experienced with waterfall approaches and are new to agile. Also assume a reasonable level of management support. How should the Scrum Master go about implementing agile practices on the team? For an experienced agile practitioner, the practices are second nature so it can be tempting to try to introduce it all at once, but the reality is that it must be gradually introduced in bite-sized chunks. The key question is which practices should be introduced first and which practices must be implemented in the longer term? Here are some suggestions:

Groundwork

Before starting the first sprint, there are some things that need to be put in place:

  1. Secure a Product Owner (PO). In many organizations this might be a product manager or representative from a business unit. This requires a serious time commitment and product insight so it should not be an afterthought.
  2. Secure a team where the people will be dedicated just to this team, rather than juggling several different projects at once. This can be a big shift for organizations accustomed to managing project assignments via resource utilization/optimization models tied to specific skillsets.
  3. Educate the team (including the Product Owner) about agile principles and Scrum. Hiring a Scrum trainer to conduct a two or three day course is ideal, but if lead time or budgets do not allow this, prepare an overview that touches on the agile principles as well as the mechanisms and ceremonies of scrum. The Scrum Reference Card and Build Your Own Scrum  are good tools to facilitate this.
  4. Be careful in comparing agile to waterfall. Disparaging waterfall will not endear agile to people who have delivered successfully using waterfall.
  5. The new PO will require additional training about what the role involves.  If they were a product manager accustomed to working with a project manager (PM), they will need to understand the additional responsibilities that get transferred from the PM to the PO. To get them started, help them understand that they will need to work with the team on a daily basis.
  6. Change the team’s physical workspace to foster improved collaboration.  Sometimes it is as simple as taking down a few cubicle walls. Other times, it involves locating people in the same area if they are spread out around the building. Be thoughtful about this. Done wrong, too many people are jammed into a small area and they can’t move around without bumping into each other. This builds frustration and resentment that leads people to resist and question the approach that brought this change. Also, an area with plenty of wall space is best.
  7. Pick an iteration length. Start short so that the team can get used to the different ceremonies and rapidly learn from its experiences. This also quickly gives the team and the organization a feel for what happens before/during/after an iteration.
  8. Populate the initial product backlog:
    • Conduct a story writing workshop. Utilize a technique such as story mapping to organize the stories. Don’t get hung up on teaching story mapping techniques – just do it by organizing stories that way on the wall. It will actually be very intuitive to people who are accustomed to structured analysis techniques. A big challenge here will be in writing the stories. If a work breakdown structure (WBS) exists as a result of the initial business case or previous project planning that was done before deciding to use agile, it may be possible to use it as a starting point for populating the product backlog.  This depends on the extent to which the WBS aligns with product features vs. technical tasks.  The more aligned it is with features, the easier it is to translate. This is an opportunity to reinforce that product backlog items are features and not tasks. Also, team members may correlate this to the design phase of a waterfall project. The focus needs to be on “what” the requirements are and not “how” they will be implemented. Stories need to be written in just enough detail for sizing, not with detailed requirements.
    •  Get the PO to prioritize the backlog by business value. Don’t be surprised if every item is given a priority of ‘1’ the first time around.
    • Create a Definition of Done. This provides the basis for sizing stories. This should include user acceptance testing (avoid the use of “done” and “done done” at all costs!). This will be challenging for a team accustomed to a UAT phase after long design and development phases. Doing this reinforces that the team should write stories that represent testable feature increments rather than individual technical layers of the application.
    • Conduct a planning poker session where the team sizes an initial set of backlog items using story points. This can be a big change for teams accustomed to having senior team members provide the estimates. During this process, the Scrum Master needs to make sure all voices on the team are heard.  Planning poker is ideal way to do this. The Scrum Master solicits input from all team members, especially when there are significant differences in estimates. So that the team does not feel as though it needs to define every last detail of each story, help team understand that this is not the last time these stories will be discussed; detailed requirements will be covered in depth once the sprint starts.
    • This next step depends on the project and organization.  If the organization views the project as an agile incubator, the team might have the leeway not to commit to an overall release plan for the product until a few sprints have been completed and the velocity is understood. If not, you may need to use an old project planning approach to derive a delivery date to satisfy the organization until a release plan can be formulated. Be very careful about providing enough buffer for unknowns – any dates that are published may become the benchmark against which success or failure of the effort will be measured. If possible, characterize any release dates as preliminary until the team has had a chance to run a few sprints.

The First Sprint

  1. Plan the sprint.
    • Set firm start and end dates for sprint. Go with either a 1 or 2 week sprint. A 3 or 4 week sprint length is not recommended because it is harder to convince PO not to change the contents of a sprint if it is longer. Also, longer sprints involve larger numbers of stories for a larger team, which can be difficult for them to manage. A shorter sprint length allows the team to demonstrate results quickly.
    • Calculate the team’s hours of capacity to do work on user stories during the sprint, factoring in sprint length, time for meetings, vacation time, etc.
    • Conduct the sprint planning meeting. The first part should involve the development team and the PO. Review the user stories on the backlog starting with the highest priority items. The team should ask the PO any questions they need to help them understand how to task out each story. The PO can stay for second part if they want. Create tasks for each story. Make tasks granular enough (max 6-8 hours) so that it will be easy to have multiple people working on each story. Continue to add stories until team’s hours of capacity for the sprint are used up.
    • Ask everyone on the team if they are comfortable committing to delivering these stories in the timeframe of the sprint and if they have any concerns or reservations.  Go around the table and ask each person – it can reveal some insights that people might not otherwise volunteer.
  1. Set up a story/task board in the team area. Even though the team might have software for sprint planning, go with high-visibility, tactile information radiators. This is important because it helps the team learn that it needs to be self-organizing/self-assigning. The team should update the board throughout the sprint, not the Scrum Master. The Scrum Master needs to change culture of having the project plan buried in project planning software like MS Project and only being maintained by the PM. This also starts to build culture of transparency with stakeholders. Invite stakeholders to visit the team’s work area to view status of current iteration. Of course, be careful that they don’t interfere by trying to change priorities or introduce new stories.
  2. Start the first sprint.
  3. Do daily standups. Start by helping team understand the purpose and the basics.
  4. Some people on the team may have heard the agile myth about “no documentation”. This is the time to start establishing culture of lean, maintainable documentation that has value through the lifetime of the product. A new team will only be able to bite off so much new stuff at one time. If they are accustomed to some type of UX or use case document, use that artifact (during the first sprint) as a transition into user acceptance test cases.
  5. Coach team members that the first thing that they need to do when they pick up a new user story to work on is to get with the PO and applicable users to discuss detailed requirements (since the team didn’t hammer out every last detail of the story during grooming or planning, right?). Reinforce with the PO that they need to be prepared to work with team members on a daily basis.
  6. While the Scrum Master’s eventual goal is a team that limits WIP and individuals self-assign tasks, don’t necessarily expect that to happen in the first sprint. Remember – people on the team are probably accustomed to having their tasks assigned to them by the PM or tech lead via project plans.  Initially, the Scrum Master may need to ask for volunteers for tasks, or as team members report that they are wrapping up a task, the Scrum Master may need to ask them which task they will work on next. Team member will typically look at the next available story that no one is working on. Steer them instead to first look for tasks they can work on for stories that are already underway but not yet complete.
  7. Start tracking the team’s burn down and post in the team work area.
  8. Run interference if the PO or other business stakeholders try to change the stories in the sprint. This is another reason to keep sprints short (max 2 weeks) at first. It is easier to argue against changing the contents of a sprint when the next sprint is less than 2 week away.
  9. Conclude the sprint on the planned end date.  DO NOT extend the sprint under any circumstances, even if it will take ‘just one more day’ to finish all of the stories. It is important to establish this early as it speaks to the sprint commitment being firm and the importance of sizing/organizing the work so that it can be completed within the iteration.
  10. Do the retrospective.  Keep the format simple initially. “What went well, what did not go well, ideas for improvement” is an easy format. Do not allow anyone from outside the team to attend. Make sure the PO attends because they are part of the team and this meeting is an important way to build trust between the PO and the developers. Ensure attendees know that the Vegas rule applies. At the conclusion of the retrospective ask attendees if it is okay to share ideas that were generated with outsiders – stakeholders will naturally be curious.  Ideas that the team does not want to share are not shared outside the team.
  11. In preparation for the sprint review, prepare a sprint summary document.  Show the team’s burn down, stories committed and status of each story at end of sprint.
  12. Conduct the sprint review. Encourage as many people from around the organization to attend as possible. This is about
    • Demonstrating results
    • Team members taking pride in their work by showing it off
    • Showing the organization that the team is transparent

The development team members (developers, QA people, etc.) should conduct the demos.

The mechanics of the first sprint described above are relatively straightforward, but the reality is that this is all occurring against the backdrop of organizational change:

  • Team members are experiencing dramatic change.  Their physical work area has changed. They are being asked to commit to delivering something without detailed specifications. No one is telling them which tasks to work on.
  • The relationship between business and IT may be very different when using an agile approach. If the PO comes from a business unit and because of the organization’s culture there exists a lack of trust or poor communication between the business unit and IT, the lack of trust and communication issues will not necessarily disappear overnight.
  • The organization’s culture may not value or emphasize teamwork. Part of management and the Scrum Master’s jobs is to build a culture where teamwork is highly valued.

The Second Sprint

In the second sprint, the Scrum Master continues to emphasize agile principles and the mechanisms of Scrum.

  1. The Scrum Master continues to coach regarding self-assignment of tasks. As the Scrum Master backs away a little bit and the team starts to self-organize, others (such as the PO) may feel that the team needs to be directed and step in to direct the team and tell them what to do.  The Scrum Master must also coach them not to direct the team.
  2. The Scrum Master continues to encourage team members to swarm on stories by default rather than only when necessary. Lessons learned from first sprint (e.g. too many stories in progress at the same time) make the purpose of this apparent.  Swarming will not happen overnight, but the Scrum Master needs to keep encouraging it.
  3. Conduct user story grooming meetings during the sprint. In the meetings, continue the mantra of discussing features at “the right level of detail at the right point in time.” Use these meetings to size out the rest of the backlog and to revisit stories likely to be worked on in the next sprint. The product owner may be unprepared for these meetings because they are already overwhelmed by working with the team on the current sprint’s user stories. Sometimes it helps for the Scrum Master to meet separately with the product owner a day or two before a grooming meeting to survey the backlog and discuss the next set of stories to be groomed.
  4. Encourage the PO to regularly tend to the backlog – not just before grooming or planning meetings.
  5. Using the team’s velocity from the first sprint, begin working with the product owner to formulate the release plan. It may not be appropriate to go public with it yet. Velocity cannot necessarily be trusted after just one sprint, but doing a preliminary release plan is valuable to get the PO thinking in terms of using the velocity and backlog to formulate a plan.
  6. Start tracking the team’s burn up and also post in the team work area.  The burn up emphasizes that hours worked do not provide business value, only completed user stories do. A graph that shows a steady burn up of completed story points during the sprint (rather than a ”hockey stick” where most of the stories get closed at/near the end of the sprint) is the goal. Don’t necessarily beat the team over the head with this…at this point just introduce it to them and call attention to each story as it is closed during the sprint.

Beyond

Over subsequent sprints, the Scrum Master should consider introducing some of the following techniques.  Of course each situation is unique so he/she will have to gauge whether or not the team is ready for each new practice.

  • For teams that are having trouble swarming and have too many stories in progress at the same time, reinforce the concept of WIP limits.  For teams that already have a task/scrum board with steps in the process laid out, the WIP limits can easily be established for each step. The team can decide whether they are firm limits not to be exceeded or soft limits that are triggers for conversations.
  • Help the team learn the finer points of writing user stories. A book study (e.g. “User Stories Applied” by Mike Cohn) is a good way to do this. Be sure to include the PO in this.
  • Test-Driven Development (TDD).  The benefits of this can be difficult for a team to grasp. Once the team (including the Product Owner) understands that it is okay to refactor and that it is simply part of progressive elaboration, the benefits of TDD become much more apparent.
  • Acceptance Test Driven Development, manual or automated.
  • Introduce additional retrospective techniques to help the team learn about itself and identify areas for growth. The Scrum Master will need to judge what type of retrospective is appropriate depending on how the sprint went.

In addition to learning new practices, the team overall needs to learn to be agile, not just to use agile practices.

  • Work with team members’ managers to help them develop a broader, t-shaped skillset that allows them to perform a larger variety of technical and non-technical tasks.  For specialists, this can be a big shift.
  • Help the team to develop an agile mindset by only learning enough about a feature to size and plan it and then really dig into the details of it once it has been pulled into a sprint. One of the most gratifying moments for a Scrum Master can be when the PO says, “We did not think of that aspect of the feature in when we discussed the story. We will just create a new story and handle it in the next sprint” – without taking the team to task for not delivering it in the current sprint.
  • When the Scrum Master has been steering the team towards new practices but the team has resisted using them, the Scrum Master may need to let the team fail for a sprint. The Scrum Master needs to help stakeholders understand that this is part of the learning process, and two-week sprints will minimize most of the damage if the team gets off-track.

Reflections

  • Every situation is different so of course there is no “one size fits all” approach to starting with agile. Organization and team dynamics impact the speed and extent to which agile is adopted.
  • As the team becomes more comfortable with the agile approach, the Scrum Master should adapt his/her approach to be in more of a supporting role for the team.
  • Occasionally the team will forget lessons learned from a few sprints ago and revert to old habits.  The Scrum Master can bring previous retrospective conversations back into focus to help the team avoid making the same mistakes.

Lean Requirements with User Acceptance Test Cases

The Agile Manifesto extols the virtues of working software over documentation as a true measure of progress and business value. Teams in the early stages of agile adoption sometimes misinterpret this to mean that they should not write anything down.  Other teams that are accustomed to waterfall and documentation-heavy methodologies continue creating extensive and redundant documentation under the guise of User Stories and Acceptance Criteria.

Lean Agile Requirements is a middle ground that provides a framework in which complex requirements are captured in living documents that speak to many audiences and serve a purpose beyond the initial development of the application. The flow for discovering and capturing these requirements in the process of developing new software appears in the diagram below.

User Story Writing Workshop

Product Owners, business representatives, and the development team meet to identify user stories. User roles are identified and a couple of sentences are written to describe the goal and value of each story. Stories are mapped into releases and become the basis of the product backlog.

Grooming

Grooming conversations occur at regular intervals in advance of the sprint in which a story is actually turned into software.  In grooming, a user story may just contain a couple of sentences describing the feature increment.  Each story is discussed and the UI might be sketched on a whiteboard or in a UI mockup tool. Acceptance criteria also may be identified – these are high-level user acceptance test cases (hint: these are not detailed tests, yet) but are only discussed/captured to the extent needed to size the story.

Sprint Planning

Sprint planning conversations are where the team starts to think in more detail about how it will build the feature increment described in a story. The discussion becomes more detailed but it is important to avoid getting into too much detail too soon (e.g. avoid things like “Should we show transactions that are less than or less than or equal to the Invoice Date?”). Any details that do surface can be captured as the initial User Acceptance Test Cases but they are not always necessary at this point. The technical design is reflected in the tasks and estimates that the team creates. Note that the user story itself does not need to contain any of this additional detail.

What is a User Acceptance Test Case?

Acceptance Test Driven Development (ATDD) is based on the premise that one of the most effective ways of communicating requirements is by understanding how the user will use/test a feature and the expected results.  Acceptance tests avoid many of the pitfalls of business rule statements because they eliminate the layer of interpretation and ambiguity involved in understanding the outcome of a business rule in various scenarios.  Writing these tests is as simple as asking the user “What tests will you run to validate this feature?”  The test cases capture the user’s actions and expected results using real examples as much as possible. For the developer, it is like having the answers to an exam before taking it.

Sprint

When the team has pulled a user story into a sprint, the first step in working on the story is to meet with the users and detail the user acceptance test cases. This is when and how detailed requirements and behaviors are captured.  Note once again that the user story itself does not need to contain any of this detail. The detailed user acceptance test cases are then used by developers, QA staff, and users to create and validate the working software.

Requirements Life Cycle in Support

Support

Once the feature is deployed to production, bug reports that are handled as support tickets may uncover additional user acceptance test cases. As the one living document that the team maintains, the user acceptance test cases are updated as the software evolves.  They are used to run regression tests to make sure that other functionality is not impacted by the defect correction.

By capturing complex requirements in the form of user acceptance test cases, the team can build and maintain a product with the confidence that the user’s needs are being satisfied.

Are You Being Agile or Doing Agile?

The GoalThe starting point for adopting agile is for a team to learn the mechanics of an approach such as Scrum.  They write user stories instead of use cases, do daily standups dutifully, and replace their lessons learned meetings with sprint retrospectives. Eventually the rest of the business comes on board, and the Product Owner takes over writing the user stories and maybe even attends the retrospectives. The product backlog gets populated in time for the next sprint planning session.  The team might spend some time talking about some of the upcoming stories before the next sprint.

A novice golfer often focuses too much on swing mechanics and less on the desired end result of putting the ball on the target.  In doing so, he is “doing golf” rather than “playing golf” and his improvement typically plateaus at a mediocre level. Agile teams can also plateau and fail to realize the full potential of an agile approach by “doing agile” rather than “being agile”.  Here are some of the smells of teams that are doing agile:

Detailed user stories

One of the principles of the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Product owners who are accustomed to waterfall methodologies may still be tempted to put all of the requirements in the user story rather than using stories as placeholders for conversations with the developers.  Detailed user stories are both inhibitors to conversation and wasteful since it makes more sense to capture detailed requirements as test cases.

Obsession with metrics

The first step in replacing traditional project management methodologies with agile approaches to is to stop equating hours worked with progress.  In agile, stories that are “done” are the only true measure of progress. As such, it can be very tempting for an organization to put emphasis on user story completion rates as a key metric for judging the performance of agile teams. The danger is that when a team is considered a failure if it does not deliver 100% of planned stories for every sprint. The natural reaction is for the team to work very hard to eliminate all uncertainty and risk before starting a sprint. This can quickly lead to a culture of big, detailed user stories and excessive story grooming and sprint planning efforts in order to eliminate all possibility of not delivering 100% of stories in the sprint. In extreme cases, a team may spend an entire week planning a 4-week sprint!

Fear of building features over many sprints

The misconception that it is best to develop an entire feature in one fell swoop may still be present in some organizations.  Usually the rationale is something along the lines of building the entire feature in a single sprint makes the process more efficient by only having to test it once.  This misses the point of agile, which is to build feature and product increments, learn from user feedback, and make adjustments by adding to the feature in subsequent iterations. This brings to mind the old adage “Users don’t really know the requirements until they fail to be met by the software.” But what about having to regression test as increments are added?  Automated testing can eliminate alot of that effort.

Stories not considered done when new requirements discovered

New requirements will surface as the software comes to life in a sprint.  That’s good!  The key is recognizing these new requirements as new user stories rather than as defects that must be corrected in order to consider the story “done”. This requires strong trust between the users, Product Owners, and development team to recognize that the new requirements were not factored into the story sizing for the current sprint (remember – requirements are not detailed before starting a story).  If team starts to feels like story is a lot bigger than what they thought when they sized/estimated it, this culture of trust allows for a new user story to be created to handle that additional work in a subsequent sprint.  The “doing agile” version of this is where CYA kicks in and the Product Owner and team members run for cover to avoid the organizational fallout from additional work coming out of a sprint.

Reflections

  • Being agile allows a team to focus on building great software that delights customers rather than merely creating the illusion of progress.
  • Just like becoming a great golfer, this is often the most challenging part of an agile transition.

Purposeful Personas and User Stories

The team was pumped to start work on the new Inventory SAAS product and eagerly anticipated the first user story writing workshop.  Bert, the product owner, had been doing a lot of up front work to make sure things got off to a strong start. The team was giddy and the room abuzz.

“Okay team, here are first stories that we should cover,” Bert announced as he displayed his list on the large monitor.

  • Inventory Quantity Forecast data column display on Item Details page
  • Customer Display page using name and address from mainframe CUST_DATA file
  • Web service calls to Forecasting system

The developers just looked at each other.

Aaron, one of the more senior developers, asked, “What is the big picture here?  What are we trying to accomplish with this system?”

“Oh, we are going to build a great new product.  I know what we need to do to beat the competition and how all of the pieces fit together so don’t worry about that.  I need for you to get this built as quickly as possible so I have been working hard to be as specific as possible with how the application should work and how it should look,” Bert explained.

Aaron asks, “Can you at least help us understand who the users are?”

Bert shakes his head.  “Don’t worry about that.  I know our users and I defined four security levels with corresponding page and data access rights.”  He displays the security levels on the monitor:

  • Guest
  • Basic User
  • Advanced User
  • Administrator

The team could start building the system with these security levels and these types of stories.  Bert could provide the exact details to the team and they could build according to those specifics.  But what would Bert and ultimately his customers be losing in working with his team this way?

A customer walks into a hardware store and asks for a drill.  Does he need a drill, or does he really need a hole in something?

On the surface, Bert is taking away the need for the team to think about what they are creating and whose jobs or lives they might improve. The team will not feel compelled to ask if there is a better way to accomplish Bert’s goals or if the product will be a good fit for the different types of proposed users. The team members will not have a sense of who they are truly working for. What if Bert instead had presented the following list of users/personas:

  • Inventory Clerk (high school graduate with basic computer skills)
  • Outside Sales Representative (moderate computer skills)
  • Branch Accountant (CPA – an advanced user)
  • IT Support (site administrator)

Now the team is in a position to better relate to the user base. Aaron asks, “Will the Outside Sales Reps need to access the application via a tablet?”

“Yes, of course.  The user interface needs to support the most popular mobile browsers in addition to the top desktop browsers,” Bert replies.

What about the user stories as originally presented? This product owner is setting the stage for his team to fall into a grind where sprint after sprint they are handed a set of stories to work on without understanding the larger purpose and meaning behind the stories.

What if the “Inventory Quantity Forecast data column display on Item Details page” had instead been written as, “Provide inventory forecast”?  This could set the stage for the product owner and team to brainstorm ways to make this information accessible  throughout the product in ways that could put them ahead of the competition. In the course of this discussion, the developers would gain a sense of purpose and commitment from their involvement in the approach and from realizing the significance of their work.

Creating this sense of purpose is one the product owner’s key motivational tools and cuts to the very core of what makes knowledge workers tick.  Product owners who do this effectively have energized teams that delight them and their customers with every sprint.

Reflections:

  • Craft a goal statement for each sprint – not just a list of stories
  • Write stories that describe the “what” not the “how”
  • Define user roles and personas, not just system security levels