Eagle Eye View

Never Eat Anything Bigger Than Your Head

2009-05-13T14:18:00.000-07:00

“Never eat anything bigger than your head”, is a simple strategy for embracing complexity. User stories are naturally shaped and sized into concepts that people can get their minds around. This is one of the most effective “tricks” in agile development. This shaping and sizing is not always easy or obvious but it is often the key enabler for agile projects to excel.

This blog entry covers User Stories, one of the “natural forces” at work in Agile Development. I plan to cover how test driven development (TDD) acts to break down complexity at a more atomic level in a future post. When agile development is working well, it grinds down complexity like ocean waves smashing rocks into sand.

As an enthusiast and evangelist for agile development I am sometimes apologetic for dogmatic agile jargon that our community seems to force on people if they want to participate in even a basic discussion. An agile development “Story” is at least one concept that is worth inviting the discussion on important distinctions from Use Cases or Feature Specifications. A story may start out as a use case or come from a feature specification, but it goes through a valuable forging process the beats it into an agile story.

The reason I like the “story” term is that it emphasizes the verbal tradition. Product owners or business analysts need to be prepared to have a conversation. The story gets hammered into size and shape by dialog with developers. As P.O.s or B.A. gets more experienced they may get better at anticipating and preparing stories of an appropriate size, but this often presupposes a lot of design decisions. So, don’t overlook the value of continually refining stories through questions and interaction with the development team.

The “three C’s” of a story given below, comes from a simple reference on writing good user stories at:
http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest

The basic components of a User Story are sometimes dubbed as the three C's:
• Card - the written description of the story, serves as and identification, reminder, and also helps in planning.
• Conversation - this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
• Confirmation - the acceptance test criteria that the user will utilize to confirm that the story is completed.

The Card becomes the physical token like a talking stick or kanban bin from lean. I know many teams are using online systems for tracking stories, so they don’t always produce a physical token. The trick with story cards is that it forces clarity in stating the story and constrains the amount of complexity. So, even if using a virtual story card with an online system, think of it like twitter, with some appropriate size limit on the description.

The Conversation is where the dirty details come out. People wonder about the role of business analysts or user experience people in agile. Their role is to be prepared to have a effective and productive conversation. This is where agile’s lightweight documentation approach wins because the verbal tradition forces clarity, and with a lively dialog the feature function concepts are tested for understanding by developers who will implement them

I call User Stories a good agile “trick” because they naturally mitigate risk. Estimation is simpler because each story has already been sized into a more predictable amount of effort. In a sense an estimate has already be made, that the story can be implemented in hours to days. This is one reason I favor shorter iterations over longer. I recommend 1-3 week iterations. When iterations grow into the 4-6 week range, the natural constraining force is not as strong and therefore risk of an incomplete or incorrect story implementation is greater.

Lean approaches further leverage this natural sizing because the story size is constrained to fit into a Kanban “bin”. This often means that a separate estimating step can be eliminated entirely because stories have already been sized to fall within some range of effort with acceptable statistical deviation.

Concurrency: Integrating Business Analysis and User Experience into SCRUM Sprint Cycles

2009-04-22T10:19:00.000-07:00

This blog article presents a model for concurrent Business Analysis (BA) and User Experience (UX) integrated with agile development iteration cycles.

How Business Analysis (BA) and User Experience (UX) can work more concurrently with development sprint cycles and maximize their contribution by eliminating wasted effort or unnecessary costs. This posting was stimulated by a Beyond Agile posting from David Castro who observed, “the BA groups and the User Experience (UX) groups really need to be working ahead of the current sprint.” While people in the discussion thread agreed with this statement, the concern was raised about how to integrate BA and UX activities into the agile development cycle and not fall into a “pipelined” development approach where detailed specification documents are created ahead of the time to sit on the shelf until needed.

This is my second posting in a series about how agile development can better leverage knowledge, expertise and practices of related disciplines. In the last installment “Tolerance” the concept of manufacturing tolerances was introduced to explain how UI / Web Designers can better guide development without “over specifying” details that either aren’t used or add unnecessary costs.

Just In Time Specifications:

BA and UX disciplines don’t claim that practitioners have all the answers, ready to give on a moments notice. They know how to solicit input from users and stakeholders and then resolve conflicts and priorities. The point is that this takes work and time that doesn’t always lead to instant answers when a developer has a question.

Ideally the homework needed to prepare for answering questions on a particular topic should happen “just in time” before it’s needed in a development sprint. This has two benefits: 1) knowledge is better used when fresh in people’s minds, 2) reduce inventory (of specs) that may not get used.

Success Factors:

BA and UX work should be concurrent with development cycles (both release and iteration)
BA & UX team members should work directly with developers
The level of BA & UX detail should be just sufficient to start and feed the development work
Finer details should elaborated as needed during (and sometimes following) the development iteration
BA/UX work product should be tracked and evaluated in much the same way that velocity and stories completed are tracked for development sprints

BA & UX should work 3 concurrent areas for each sprint or development iteration:

1. Prepare for the next sprint – Create Specifications For Development

2. Actively contribute to the current sprint – Software Development Sprint

3. Use running software from the last sprint – Solicit Software Feedback

Here is a diagram showing these as 3 concurrent work cycles

This diagram is presented from the BA or UX view to show the work activities they would be involved with during any one sprint cycle. If your development team uses a two week sprint cycle, then BA and UX spend some of their time during each two week cycle preparing specifications for development in the next sprint cycle, some of their time working directly with developers on stories in the current software development sprint, plus some of their time gathering and filtering feedback from people running software created by the previous sprint cycle.

It’s useful to look at a simple value stream for this, in order to understand what you may want to track and measure for continuous improvement, What roles (disciplines) are involved, what is their work product (value added outputs), and who consumes or uses it (inputs). The following diagram remaps the concurrency diagram above to show a stylized value stream map with inputs and outputs. This map uses a sprint cycle symbol for processes in the map to emphasize that these are: 1) time boxed activities (cycle time = sprint cycle time); 2) performed concurrently with the prior (n-1) sprint, current (n) sprint, and following (n+1) sprint.

Agile Development Concurrent BA & UX Value Stream

Roles & Responsibilities

Adding business analysis and user experience to the agile development mix does add a level of specialization in addition to Product Owner and Scrum Master roles. Generic SCRUM would list BA and UX as part of the “Team” with "their bacon on the line." Much like a Product Owner, they have responsibilities to prepare ahead of each sprint, as well as participate in each sprint. One way to look at these roles is as an extension to the Product Owner role, which has a big job to do understanding and prioritizing the wants and needs of many different customers and stakeholders. This pattern has been applied successfully designating a “feature owner”, to whom the product owner delegates the breakdown from a release level feature into story level details and acceptance testing.

Product Owner Responsibilities

Product Backlog
Product Roadmap
Sprint Backlog

Next Sprint (n+1) Backlog or “wishlist”

BA and UX need to have visibility on what to prepare for at least one sprint ahead of time and this should come from the Product Owner. This is always subject to change. A good Product Roadmap can help in forecasting stories a sprint ahead.

Business Analysis Responsibilities

BA Domain Model - provides consistent concepts and terminology
Feature Specification (aka Story Outline)

User Experience Responsibilities

UX Design and Interaction Standards
Personas or Representative Customer Profiles
UI Storyboard (UI sketch “wireframe”)

BA and UX Specification detail should be just sufficient to start and feed the development work.

This article mixes agile development language with more traditional development language for BA and UX deliverables. While the deliverable names may be familiar the contents need to be adapted for agile development cycles.

It’s helpful to think of a Feature Specification as a story outline. BA should collect the information they need to tell a good story in the Feature Specification:

Who, What, Where, When, Why:

Who are the characters? Aka: use case actors, personas, customer profiles
What do they want to do?
What stuff do they deal with?
Where does the stuff come from?
When do things happen? Plot or scenario that ties the story together
Why do they care?
Why do we think this story will satisfy their wants and needs?

In a similar vein, user interface designers have borrowed the “storyboard” concept from the movies, using sketches or storyboards during the early stages of user interface design. The earlier “Tolerance” blog article talks about tradeoffs for UI “sketches” versus precise graphic layouts.

Finer details should elaborated as needed during (and sometimes following) the development iteration

In most cases, defer specific details for exactly “How” the software is going to work to the development cycle. Time boxed specification cycles act as a constraint to limit any tendency to create too much unused detail. Another way to think about using feature specs or UX designs is as study notes or presentation materials that BA and UX people refer to when talking with developers and testers, rather than static documents for bed-time reading.

Realize the Value of Running Software

Running software is a valuable tool for business analysis and user experience. It may be prototype, alpha, beta, or release. If people actually use it and experience it they will give feedback. Agile teams often don’t utilize the “potentially shippable software” from each sprint iteration. In many cases, it is like inventory sitting on the shelf until it all gets packaged into a release.

The “Solicit Software Feedback” process is one of the keys to successfully balancing the level of specification detail because it is the ultimate test of whether a story satisfies customer wants and needs. BA and UX become consumers of the running software delivered by developers and testers in this step. They are responsible for getting more immediate feedback into the agile development loop sooner. People in these disciplines have skills for usability testing and software validation. These practices encourage users to explore and experience a broader range of software functionality, sooner and to maximize the useful feedback gathered from them.

BA and UX are also responsible for collecting and classifying Issues and/or Defects versus New Features for the Backlog. There is some debate in the agile community about the value of differentiating between defects/bugs, issues and just another story. Many organizations separate these into maintenance and enhancement categories. In this case, there is value in distinguishing whether a story satisfied the desired capability for the target user or not. Is there a bug or issue that we missed in acceptance testing? Did we flat miss it, or now that we have running software did we see something new?

BA and UX Solicit Software Feedback Responsibilities:

Issues/ Defect

Problems discovered during user testing for immediate triage and possible insertion into the current sprint

New Feature / Enhancement

New features or stories that add capabilities or enhance usability in ways that weren’t anticipated or intended

User might say,

“Yes, I can and would use it as is, but it would be if…”

“Now that I can do X, I can see how I also want to do Y.”

Rework

A complete story rewrite is required to complete any level of functionality that is useful to a customer.

BA/UX work product should be tracked and evaluated in much the same way that velocity and stories completed are tracked for development sprints.

The best judges for the level of specification details are the specification consumers. In this case developers and testers are the consumers. BA and UX should let them guide what details are most useful in writing and testing the software.

Tune your process to achieve the best balance of just in time and just sufficient BA & UX detail. This will give you something controversial to talk about at Retrospective meetings.

Some questions to ask from developers and testers in the current development sprint:

· For each specification given as inputs to sprint stories, did someone actually use the specification?

· Was it clear and useful?

Did lack of detail or missing background information cause delay? Possible consequences:

· Developer had to wait a day or more to get answers.

· Story had to be deferred to a later sprint so that BA or UX could research needed information.

Tolerance

2009-02-19T11:05:00.000-08:00

This post is about using tolerances as a way to reduce costs and add value using Agile Development practices.

I recently attended a session at Agile Open Northwest called “Up Front Design - how much is too much?” I think the original intent was to focus on “technical design” for how to code, but it quickly diverged into a broader discussion about how other disciplines such as Product Management, Usability Engineering, and Web Designers influence software design by the way they specify their requirements.

One design influence is how Product Owners (aka Product Management) are asked to break larger features into smaller, more digestible chunks, (aka story) that can be implemented and delivered in running software by the end of each sprint iteration cycle. The agile advice is that as much as possible about a story should be “negotiable”. This is good advice as far as it goes, but what are the boundaries? Clearly there is some point to the story that is not as negotiable, otherwise why not just let a developer make it up. Giving a tolerance is a way to be clearer about what is negotiable and what is truly needed.

There were several Web Designers and User Interface Design people in the session who described how precisely they did page or screen designs. Their usual tools allowed them to specify size and position to the pixel, along with font sizes that fit just the right text string in a given space. This seems to be a common practice for a complete and detailed UI or Web page designs to get handed off for development. The UI and Web Designers in the session asked, "Why wouldn’t you want us to tell exactly how we want the screens to appear? Doesn’t it make your job easier if we have already figured this out for you?" The agile response was, “You will get better value if it’s more negotiable, and that it’s better to iteratively work with developers to figure out what is really needed.”

This conversation went back and forth. Agile YAGNI (You Aren’t Going to Need It) countered with, “but it’s our job to determine what users need.” A related agile principle, “defer design decisions to the last responsible moment”, countered with, “why should we wait when we already know it’s important.” This wasn’t an argument about the right and wrong way to do things but a conversation about the best way to work together. Several suggestions were given about the value of reducing the fidelity or precision of the UI spec by using paper sketches. A UI design tool that was intentionally “cartoonish” was also mentioned (I hope someone will comment on the name of this since I didn’t get it in my notes)

This was where the concept of tolerance came in. In manufacturing tolerances are used to specify where you need ultra-precise dimensions for a bearing fit or where you only clearance so it doesn’t rub. It is much more expensive to machine a +/-0.0001 inch bearing fit than to stamp out a +/- 1/32 inch clearance. In Lean Manufacturing over specifying tighter tolerances than are actually needed is considered “waste” because it drives up cost and manufacturing time, without adding any value.

Tolerances were common ground that that both agile developers and UI/Web designers could relate to. The agile developers related a simple case, if you only care that a button is on the right or the left of a screen, it’s faster to implement than if you ask for it to be located within 1 pixel. The UI and Web designers also related that tolerances would allow them to be clear about the critical aspects of their UI design while giving some leeway for what is more negotiable during implementation.

Agile Open Northwest 2009

2009-02-16T09:13:00.000-08:00

I recently attended Agile Open Northwest in Portland, Oregon. This conference used the Open Space approach which resulted in some really good interactions about Agile Development. The theme was "Agile for Real" and it was great to talk with other practitioners about their best practices and lessons learned.

We had time slots for eleven sessions over the two day conference and different people hosted about six different sessions for each scheduled session time. I hosted or co-hosted three sessions during the two day event. This was my first experience with an Open Space event and I quickly learned that asking questions and facilitating a conversation among all of the people in a session was most productive.

One of the issues I am most concerned with is how Agile Development can do a better job of working with the talented people in other specialized disciplines across an organization. I am concerned when I hear some agile experts answer with a pat “That’s not Agile” to questions and concerns from people outside development. It seems like business stakeholders often hear this when they ask for a long term schedule and commitment to certain content. I had the pleasure of co-hosting a session with Scott Porad on “How to give a long term schedule”. Scott did a great job of continually returning to ask the question and the result was some really practical ideas on how to come up with a schedule for a committed list of content and also how to communicate it.

You can read our session note on the AONW wiki page at:

http://agileopennorthwest.org/wiki/index.php?title=How_To_Give_A_Schedule

One of my goals following this conference is to encourage conversations about how agile development can better leverage knowledge, expertise and practices of related disciplines.