Tag Archives: user stories

  • -

Improve Measurably with Improvement Stories

Tags : 

Americas cup 2013 race

The Americas Cup, started in 1851, is the oldest international sporting trophy. In 2010 the Cup was disrupted by teams using multi-hull trimarans with fixed wings instead of sails. By 2013 fixed wing catamarans with hydrofoils had sailed at 3 times wind speed.

One of the continuing challenges we see with some Scrum teams is a lack of improvement in how they work over time. There are many reasons for this, however continuous improvement is the cornerstone of Lean thinking, and the reason we have a retrospective in Scrum.

There are many ways to improve. Lean thinkers advocate the A3 plan for improvement, an excellent way of thinking about larger improvement efforts. You will often hear Lean thinkers talk about “Kaizen events,” Kaizen is Japanese for improvement, and these events are focused efforts to implement improvement. In Lean, Kaizen is a mindset, the search for improvement is continual and a critical part of day to day work of everyone.

In the software community we have numerous good ideas for improvement including Retrospectives, Devops, and automation.

However all improvement starts with deciding to value making the improvement over producing something else, like a feature or a bug fix. This is usually where the problem starts. Teams and Product Owners tend to value new functionality over improvement. From the perspective of a long lived product development effort, every improvement made is an investment that pays off for the lifetime of the product. For example an improvement that saves a team member 10 minutes every day may seem too small, however if that 10 minutes is saved over a 2 year period, that adds up to about 5000 minutes or 83 hours. That’s more than two weeks of productive time that can be spent on more valuable activities. A recent study of the most productive software developers at Google found that they spent approximately 1/3 of their time building tools to improve or automate their work environment. If the best of the best spend 33% of their time sharpening the saw, then shouldn’t the rest of us should make similar investments?

Changes to Scrum that prioritize improvement

Jeff Sutherland, the inventor of Scrum, in discussion with Lean expert Hugo Heitz realized that Scrum teams weren’t realizing their potential because they didn’t proritize improvement. Since then Jeff has advocated the pattern “Scrumming the Scrum” where teams use the Scrum cycle to improve Scrum. The twist is that the improvement is the first thing the teams do, before working on any new functionality. To implement this change the Scrum board gets another swim lane, the improvement or kaizen lane.

scrum board with improvement lane

By breaking out the improvement in its own lane and putting it a the top board, we attach the visual and social importance to improvement. We are making a clear statement to stakeholders that investing in improving how we work is more important then any one piece of functionality.

Describing incremental improvements

User Stories first emerged from the XP community in 1998 as part of the planning game. Over the past two decades there has been much work on improving User Stories and Acceptance Criteria. This thinking has clarified both the mechanics of User Stories and the value of the different features of the format. There have also been a number of variations developed. As the Agile community refined User Stories, it also borrowed good ideas from the EVO methodology developed by Tom Gilb. Gilb defined System Qualities to specify needs the system must meet that were not features (non-functional requirements).

To date the Agile community hasn’t really defined a good way of describing improvements. The Lean community has A3 plans that are very are useful but often are too large to fit in a Sprint. The A3 format also tends to be a mini project with a number of changes, deliverables and measures, while in Agile and Scrum we use iterative and incremental delivery. So we need a way to define improvement that leverages iterative delivery and our previous learning about describing user and system needs.

What is an improvement? This is an interesting question. Is it a feature? Maybe. Is it a process change? Possibly. Is it a tool? Could be. Is it a social agreement? The interesting thing about improvements is there is a wide range of things we may do to improve our situation and how we work. Given there is such a wide range of possibilities, this is similar to the Feature/function in User Stories. So let’s look at how we can leverage user story thinking for improvements.

User stories consist of 4 parts:

  1. The user role
  2. The feature or function
  3. The benefit or goal we are trying to achieve
  4. A definition of done in the form of Acceptance Criteria

In more general terms we can say that user stories are of the form Who, What and Why. User stories are powerful because we bookend the thing we plan to build with two important pieces of information, who is going to use it and why they want it. This means we need to find an actual user and validate that they really do want the functionality. We also need to understand why they want it in order to prioritize it against all the other things we might do for our users.

Looking at the work of implementing improvements we see a similar need. There are many different improvements we can make, how do we prioritize them? Who benefits from the improvement? What benefit do we expect to receive? How do we know we received the benefit? Given these questions are similar to questions we have  answered with User Stories we can leverage this thinking.

Measuring Improvement

While it is great to say we have improved, it is more interesting to say we have improved by a measurable amount. If we are investing time and energy in improvements that could be spent on functionality that generates business value, then we should try to show how improvements provide quantifiable benefits. To define a quantifiable improvement we need to determine:

  • What we are measuring
  • How we will measure it
  • The current state
  • The (anticipated) improved state*

*this is likely just a guess

By making clear statements about measurement we force questions about methodology and we make it more transparent how we intend to quantify the outcomes.

Creating an improvement story

Defining “who” in an improvement story:

Since improvement stories may impact team, process, stakeholders, users, management, we have a broad number of potential roles. Choose the role most closely associated with the benefit, and involve them with measuring the improvement.

Defining “what” in an improvement story:

The improvement needs to be do-able. This means if we pull it we can get it done within the Sprint, and we can see a result from the work that provides a benefit we can take advantage of next sprint.

Defining “why” in an improvement story:

Why are we making the improvement? What waste are we eliminating? What aspect of work is improved? What increases do we expect to see for the defined Role?

Knowing when we have improved:

It isn’t enough to say we have improved. We need to find ways to quantify the benefits. How can we measure the improvement?

Example improvement story:

During their retrospective, a Scrum team comes up with a number of improvements they could make in the next Sprint. The team decides there are two improvements they will tackle in the next sprint, reducing the time to install new builds onto the QA server, and improving communication with another team who they rely on.

The team crafts the improvement story together during the retrospective.

Starting with “why”:

The team defines the expected benefits, with testers talking about the time wasted waiting for a new build and developers complaining about getting hassled by testers for a build, having to stop working on a feature to run through a bunch of tedious manual deployment steps. Both developers and testers will benefit, so they decide to write the improvement story both ways for fun. The testers do some quick calculations and determine that on average they will save an hour per day per tester. The developers determine they will save 15 minutes per day per developer. Both developers and testers expect this change will improve team working relations by eliminating at least 2 or 3 conflicts per week, reduce multi-tasking and make the team happier.

What can we do to improve this sprint?:

The team discusses the possible solutions they could pursue, from implementing a new build server to automating database configuration. As a first step the team agrees to write deployment scripts that will automate copying the current build from the development build server to the QA server and run a smoke test. Since database changes are less common they choose to defer automating database updates to a future improvement. The team writes up the improvement story from the tester point of view:

Automate QA Builds – Tester  

As a tester I can run a script to get the latest working build on the QA server so that I save 20 hours per sprint and don’t have annoying conversations with developers.

We know we will have improved when:

  • We have reduced tester wait time as measured by testers using a stop watch
    • From the current state of 20 hours to 5 or less hours per sprint
  • We have reduced team conflict about getting builds as measured by red postits on the scrum board
    • From the current state of 4 to 6 conflicts per sprint to 1 or 2 per sprint

  

And then they write it from the developer point of view:

Automate QA Builds – Developer

As a developer I can write a script to automate getting the latest working build on the QA server so that the testers will stop bothering me 3+ times per day for the latest builds.

We know we will have improved when:

  • We have reduced number of times I am bothered as measured by “build please” postits on my monitor
    • From the current state of 30 times per sprint to 5 or less per sprint
  • We have reduced team conflict about getting builds as measured by red postits on the scrum board
    • From the current state of 4 to 6 conflicts per sprint to 1 or 2 per sprint
  • We have reduced the time to get feedback on my bug fixes as measured by the bug tracker
    • From 3-4 days to 1-2 days 

In creating these improvement stories the team has agreed on what they will measure and how they will measure it. By agreeing to put red postits on the Scrum board every time there is a conflict the team creates visibility about the aggravation (or lack of) caused by the friction of the current system.

The team realizes there is an additional important benefit from making the improvement. Not only will it eliminate wait time and frustration for team members, it will also speed up feature development, since testing, bug fixes and validation will happen in a shorter timeframe. The team likes this benefit but isn’t sure how to measure it, so they leave it as a topic for next retrospective.

Sizing and Decomposition

As with User Stories, Improvement Stories can be written at both a high level and detail level. They can be sized using story points, and can be decomposed into the specific tasks the team needs to get the Improvement implemented.

Improvement Story Templates

There are two different templates you can try for creating improvement stories

Template B “Start with why.” This template emphasizes the importance of why more than the standard template.

improvementstorytemplateB

 

Template A is likely more familiar to most people who are using User Stories.

improvementstorytemplateA

 

We hope adding improvement stories will help you implement continuous improvement within your team and organization. Stay tuned to Innovel for additional writing and examples on improvement stories.


  • 1

Dude! Where’s My Backlog? The People and Process of Product Ownership.

Tags : 

In September 2010 I gave a keynote talk at Agile Eastern Europe called “Dude, where’s my backlog?” The talk covers the common pitfalls seen with Product Owners and the Product Backlog. The talk covers the people that bring a product backlog into existence and the processes they can use to maintain it. This includes using ideas from Kanban for personal process and modifications to Scrum for more frequent involvement of the team in maintaining the backlog.

Robin Dymond Keynote: “Dude, where’s my backlog?” from Agile Eastern Europe 2010


  • 3

Agile User Interface Design and Information Architecture from the trenches

Tags : 

I was a technology Director in a large web design company 6 years ago, and they failed to adopt Scrum. There were numerous management dysfunctions, however the Creative managers were the most resistant to change. Often this resistance was a case the creatives not wanting the reality of building enterprise software to hinder the design concepts they were making in Photoshop or Illustrator. When these design concepts met the reality of enterprise architectures on the development floor there were major implementation problems. This dysfunction, along with high pressure, unrealistic delivery dates and long hours resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company for a short time spurred my interest in User Interaction design (UX) and Agile, and I have since found basic solutions that work when people want to do UX and Scrum. To date (2011) I would say that of all the disciplines needed for creating software and especially web sites, people coming from UX background are often the slowest and most resistant to adopting Agile principles and practices. I think this comes in part from the influence of Allan Cooper’s book “The inmates are running the asylum.” However Allan Cooper, himself a practitioner looking for solutions that work, embraced Agile and Scrum since 2008, if not earlier.

Here is the way I work with UI Designers and Information Architects who want to work Agile:

    1. The Product backlog and its priorities drives all the work. We work from business priorities not UI priorities.
    2. Sketch the highest level level UI for the site. No drill downs into buy flows, just top level.
    3. Look at the backlog and start thinking about what the team will need for UI half an iteration ahead.
    4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don’t embellish with new features the designer thinks are needed. KISS. Include validation and other acceptance criteria for data fields.
    5. Create and maintain a style guide and reference it as required. Create and use reference page templates as required.
    6. Combine 2,3,4 above into a 1 page design spec. to support the UI needs of a user story.
    5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
    5a. Check in design docs, version them.
    6. Participate in sprint planing with rest of team.
    7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/Javascript etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (see tools like Rspec, Cucumber, etc).
    8. repeat for every sprint.

To recap the UI designer starts half a sprint ahead of the team, helps the Product Owner with UI issues, and creates very lightweight and flexible prototypes as input to sprint planning. The rest of the work is done within the sprint. I have found this is “just enough” lead time to have thought through UI issues without creating solutions in a vacuum away from the team.

Additional tactics:

  • Create a style guide for the team and have them read it, listen to their feedback and continuously improve it.
  • Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
  • Break dependencies between UI/layout and business logic at beginning of the iteration. Agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.
  • Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don’t worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
  • bad idea ui tool

  • AVOID COMPLEX HIGH FIDELITY USER INTERFACE DESIGN TOOLS. They really slow you down and lock in decisions far too early. These decision are often wrong.

Lack of detailed knowledge about the customer needs and technical limitations can result in an unstable UI. This lack of understanding results in an unclear product backlog and user stories coming into the sprint. To cover these gaps the UI person has to go find out the missing details to create the design, which slows them down and results in numerous design changes during the sprint. The UI designer is making up for lack of knowledge or lack of effort on the part of the Product Owner. Fix this root cause by getting the Product Owner to improve the product backlog so the designer and the team have better user stories and acceptance criteria coming into the sprint. User Interface work is simply another form of software requirements, as are software architecture, features, and test plans. All of these activities can be done in a “just in time” and emergent fashion and result in consistent architectures and usable interfaces. As User Interaction designers it is important to focus on the end result, great software, and to help the team realize that goal. The UI design artifacts: wireframes, clickable concepts, specs, etc. are often over-valued by UI designers. These are tools in our toolbox and are not essential. Choose the tools and the collaboration model that takes the least amount of time and offer the greatest impact on the goal of delivering great software. That goal is best achieved by working side by side with team members building the software. Many are doing it today. However it does require people to change their behavior, and that is likely the hardest thing to do.


  • -

Oracle, databases, Scrum and Agile

Tags : 

I recently read a great post by Cary Millsap, an influential member of the Oracle community on Oracle and Agile. I have read both of the books Cary mentioned, they are excellent, and the Goal by Eli Goldratt is outstanding, if you haven’t read it, put it at the top of your list. It is a novel and has nothing to do with software.

I don’t really understand why Agile is not embraced by the Oracle community. There are lots of reasons why it can make a developer’s life better, and it doesn’t matter whether it is coding SQL or Java. However from a DBA perspective, I think having changes committed to production DBs every week or two is scary, especially if you are the one carrying the pager and responding to 4 AM outages (and why do they seem to mostly occur at 4 am?).

For Agile to be successful we need to deploy early and often. For production stability and performance we need to quantitatively know deployments are going to work just as well or better than the last deployment. There need to be safeguards put in place to address the risks, and systems that reduce or eliminate the transaction costs of doing deployments. As mentioned in Cary’s post, automated testing plays a huge role here.

Here’s one way of stating the DBA’s needs in the form of a user story:

As a DBA I want to have a stable, high quality database to monitor performance and tune so that I can maintain data operations and improve system performance.

Acceptance Criteria:

  • New database releases to production must contain all the performance improvements implemented in production to date.
  • All DB changes must have automated test coverage that quantify whether or not the DB changes implement the desire inputs and outputs correctly
  • Any DB change found to not function correctly can be rolled back without impacting the rest of the DB
  • All changes between production deployments are automatically calculated and displayed to DBAs
  • Production Databases are stable and not changing between the regular release cycle.
  • DBAs collaborate with and are consulted by the team(s) implementing DB changes
  • DBAs provide weekly mentoring and DB code reviews with team members implementing changes
  • (Please add your additional acceptance criteria)

What changes you would need to implement in your organization so that the above user story were true?

If you are a DBA working in a small company next to developers and QA, then maybe it is changing a few of your practices, working more closely with the other developers on DB changes, implementing test frameworks like DB Unit, getting SQL code into version control, implementing a DB change management tool like Liquibase, and creating a better rollback strategy.

If you are in a large bank sitting with 15 other DBAs at the backend of a manually intensive, form driven, cost managed, outsourced deployment process, you have some work to do :). The goal and many of the steps are the same as with the small company. Ironically, the bank has many more resources to implement these changes. However the management hierarchy and organizational silos make it much slower and more difficult to implement these changes. So what do you do? Well you can continue to stay in your DB team silo, complain that Agile is the problem and be the victim. This means that most interactions with others wanting changes will be negative, you will be viewed as obstructionist, and that cute tester will think you’re a jerk. Another approach would be to remember that we are all on the same team, and go for a walk and meet the Agile teams to see how you can work together. You might take this blog and the user story above, show it to the ScrumMaster, Product Owner and Developers. Start a friendly discussion about how your needs for a reliable, production friendly DB can be met in the context of regular production releases. Remember that by doing this you are asking them to change as well, and since you are both changing, the situation becomes problem solving together. One more point, expect mistakes to be made and occasional firefighting on the road to a more effective development and database operations process. The changes are non-trivial, the results can be amazing, and the journey is the most memorable part of the experience. Bon Voyage!

Thanks to James Thomson for the inspiration on this one.


  • -

Agile Belgians, Trappist Beer and Paper Prototyping

Tags : 

I was recently in Ghent, Belgium to give public training sessions and a talk at Agile in Belgium. My colleague and friend Jurgen de Smet and I conducted a Certified Scrum Master class, and I launched a new one day intensive course on User Stories, Paper Prototyping, Agile Estimation and Planning. Jurgen did a very nice write up on the class on his blog User stories, paper prototyping, estimation & planning where he outlines the course and his impressions. However he didn’t mention the business case. The business case is the development of a Belgian Beer portal to sell the many hundreds of varieties of Belgian Beer! For those who don’t know lager from ales, the Belgians are world beaters at creating and selling great beer. The largest beer companies in the world are based on Belgium. In fact Budweiser’s parent company was recently bought by the Belgian-Brazilian company InBev, the world’s largest brewer. What has this to do with Agile, Usability and Scrum? Well if you are going to fulfill the business case for supplying large markets with the many niche beers of Belgium, why not use Scrum? It is the fastest way to go from customer need: I am thirsty for a Trappist monk brewed beer, to need fulfilled. Ahhh! that is a fine ale. Of course if you are in Belgium, then a trip to the store is probably a little faster and cheaper. The business case gives participants a specific market and product with its technical and non-technical challenges. The Product Owners need to account not only for the features and the web site but what other things need to be done to get the web site off the ground. The exercise is to recognize the resources are scarce for all the work required, and how do the decisions made in one area, for example fulfillment, impact the site features.

Belgian Beer Portal Paper Prototype!

Working on the paper prototype. Here the discussion is about what really is the minimum UI and functionality the portal can enter the market with. Like any web site, there is always more to do… but what can you afford to prove feasibility of the business case? Belgian beer can aid with these agile discussions.

If you are interested in having the User Stories, Paper Prototyping, Agile Estimation and Planning course taught publicly in your area or for your company, please contact me at rdymond atdeletethis innovel.net. I have other business cases that we can use for the same exercises.