Due to time limitations, I was able not to get to all the questions from my Analysis in Agile: There’s More to it than User Stories webinar last week. As promised, please find my thoughts below:
Q: We rely on story workshops to build our stories, should we use models instead?
A: I don’t think story workshops and models are an either/or sort of thing. Story workshops are good in that they (hopefully) get the right people together to focus on identifying the right thing to build. However, without having the unifying big picture that models can provide, it is very easy for those story workshops to produce a product backlog with the two issues I mentioned in the webinar – a wish list that represents an incomplete solution.
That doesn’t mean that you should not use story workshops, instead figure out a way to incorporate figuring the big picture via models first, then using that understanding to identify your stories. Change the agenda of the story workshops so that you first agree to the goal of the project, then work as a group to describe possible solutions using models. Then use those models as the basis from which you start identifying your stories.
Q: Are there specific work environments for which we would prefer either stories/models etc.?
I don’t think stories and models are mutually exclusive. They serve different purposes. Models are extremely helpful for describing what the solution should look like, and stories are helpful for planning how you are going to parse up the work. Looking at it from that perspective, stories and models are actually complementary.
Once your team gets quite experienced, you may chose to go away from the widely accepted user story format of:
because your team gets enough information from something along the lines of “Submit Review”. But you still may find that having models, acceptance criteria, and/or examples to describe the story as helpful.
What may vary is in what situations you would use one or more of acceptance criteria, examples, and models. You may also see some variation in which types of projects use which types of models. That really depends on the nature of the project.
If, for example, you are working on a website, you most likely will use wireframes and examples as your main ways of describing stories.
If, instead, you are working on a business intelligence application and most of your work is in providing data that may have some transformations applied to it, you are more likely to use acceptance criteria (describing the data elements used) and examples.
There is no clear cut answer, except to say when starting a new effort, make sure the team discusses “What combination of supporting information is needed to help us deliver value effectively?” In other words, “What is our definition of ready?”
Q: Are the stories formally connected to the models? Should they be?
A: If you create some fairly broad scope models and then use those models to identify stories, you may find it helpful to note which stories represent changes on the model so that you can keep a running tally of all the changes you have made in the context of the model. You can think of this as release notes to indicate when specific changes are being made. Converting stories into release notes can be extremely helpful for this.
If models are being used to provide more detail about stories, it is probably best to reference which model provides more information about that given story. If you build your models to describe the system overall and are intended to live beyond the project in the form of system documentation, then it’s probably best to have those models in one location and provide a reference to those models in the backup information for that story. I’m assuming that you have some sort of electronic story repository, such as Jira. If you do, just put a link to whatever models support that particular story. If you craft a model specifically to support a given story, it’s probably ok to draw rough sketch, and then attach that sketch to the information about the story into your story list.
As another way of answering your questions – if formally connecting stories to the models helps you better meet your customer’s needs, then do it. If that step does not, don’t do it. Pretty much my advice for a lot of practices.
Q: To prevent the analysis bottleneck, shouldn’t you avoid a set list of model deliverables and provide what is needed by the team to clearly communicate the story?
A: Yes, you should always provide what is needed by the team to clearly communicate the story. That’s the purpose of models. The reason I suggest a definition of ready is to dramatically reduce or eliminate incessant discussions about what is/is not needed on a user story by user story basis. The definition of ready helps establish expectations about what the delivery team will have available when they start trying to work on a given story. As with many other practices in agile, it’s often the conversation that goes into identifying the definition of ready that is much more helpful and important than the definition itself.
The definition of ready provides a baseline agreement on what like to have in place for stories. As the team progresses and they find some of the information to be not as helpful, the team can adjust their definition of ready accordingly.
Q: Consensus is difficult to get. Any guidance?
A: Yes it is, and I have seen in too many cases where the desire to get to true consensus resulted in no decision being made, or a decision being made later than it should have been.
When I talk about the team discussing the definition of ready, I am not looking for consensus from the team. I do want them to support whatever definition the team comes up with, even if they don’t agree with absolutely everything that’s on it. That’s why the discussion aspect of the definition of ready is so important.
Q: Have you seen story supplemental artifacts also serve as living documents for the system?
A: I can see “system level” models, such as business process flows work as good living documents – where you create and update those models as part of the project with the dual intent of having them live on after the fact.
Models such as user interface prototypes, and data models I tend not to hang on, mainly because you can see what the interface looks like by looking at the system, and you can easily recreate the data model from the actual physical database.
Other things I find helpful to keep for reference after the project include business rules and metadata, but I will typically update these things in parallel with or shortly after development. I don’t necessarily use the artifacts that were created to describe the story (i.e. getting to ready) because there is a good chance that things could change during development.
User stories also make a good input for release notes.
In general, system documentation is good if it is written explicitly for the purpose of supporting the system and organized in a way that’s intuitive for the people supporting the system (which usually isn’t based on which project the change occurred.)
Q: Any way to help manage scope?
A: Scope management in an agile environment occurs in a few different ways. Starting off, it’s very helpful to establish one or two SMART Goals that the project is intended to help the business meet. These become measurable indications of value the team can use to determine if the project is heading in the right direction. By creating decision filters from these goals, the team can easily manage scope by excluding any features or stories that do not lead to direct accomplishment of that goal.
As an example, say you had a goal that stated “By December 31, increase inventory turns from 5/year to 10/year.” Your decision filter for that particular project is simply “Will this help us increase inventory turns?” Then when you are reviewing stories, you run every story up against that decision filter. If you can’t answer “yes” for a given story, don’t do it. Don’t even add it to the Product Backlog. It’s not getting you toward the goal for your project.
Another scope control mechanism is the Iteration Planning meeting (if you are running your project in an iterative fashion). Once the product owner and the delivery team agree to what is included in an iteration, that can’t be changed. The delivery team knows they can focus on those stories for the next 2 weeks without having to worry about someone coming in and making a change.
Also, check out my co-worker, Jacqueline’s, post on Scope Creep’s Impact on Analysis.
Q: Do you see the product owner defining what value is received from the project? Seems like a business strategy discussion that then shifts to team.
A: Generally speaking, I’d expect that the project was started in order to achieve some sort of business goal. Whether or not it is initially a measurable goal may be up for some debate, but there usually is a business reason for starting a project. This is usually coming from a Sponsor (who in some cases may also be the Product Owner, or may be in the same organization as the person acting as Product Owner.) The sponsor is providing the vision, and identifying the reason for doing the project.
The team will certainly get involved with the discussion for a couple of different purposes:
- To build a shared understanding of vision/purpose goal of the project among everyone involved. Just writing the vision down and expecting everyone to read it is usually not sufficient. People won’t internalize it the same way the sponsor intended it. It’s better to discuss it in order to get everyone on the same page. Exercises such as the Product Vision Box or Problem Statement can help structure those conversations.
- To help identify the measurable goal that coincides with the vision. In many cases, the Sponsor may know what they want to accomplish, but may have difficulty conveying that information into a measurable goal. The team can help by providing input on what information is available and ways that it can be measured.
Q: If user stories are left at a high-level and general, where do you capture the low level details that “live on” and are documented? Typically, we have the requirement documents that serve this purpose.
A: User stories (I’ll call them simply stories in the rest of this answer) are not particularly high level – they represent changes that can be done in less than 2 weeks and get fairly specific. They do stay at the level of describing what someone wants to accomplish with a solution and stays at the level of “what”.
As I discussed in the webinar teams will often use models, acceptance criteria, and examples to further describe stories in a way that is suited specifically for the purpose of aiding communication between the delivery team members.
Determining a Definition of Ready helps the team coalesce around which of those particular techniques they feel would be most helpful for them to describe the story.
Remember, stories are placeholders for future conversations. Depending on how your team works together, you may have more or less documentation based on how much help your team needs to appropriately communicate the business intent of your stories.
Q: Is there a general rule on when a particular user story should be complete or who decides on when it should be completed? Also, does this timeframe include all the analysis, development, testing, and screen design as part of the user story completion?
A: Similar to the definition of ready, many teams establish a Definition of Done that describes what must have happened to a story in order for it to be considered done. In many cases, this includes developed, tested (varying levels depending on the team), documented, and PO Ok’d. The team establishes this definition early on in the project and apply it to every story. If the story does not meet the definition of done, it’s not done.
When you are delivering in an iterative fashion, the iteration itself includes anything necessary to get from the definition of ready to the definition of done. If you don’t have a definition of ready, then the iteration may include everything necessary to go from a story (As A, I Want, So That) to running tested software, which may include analysis, development, testing, and screen design as a well as other things.
Most teams working on more complex systems find that they have to do some analysis a bit ahead due to the complexities. That’s where the definition of ready comes in handy.
Q: Are you capturing business rules as you go through the story…getting to ready, perhaps?
A: Business Rules can be identified in two different ways when it comes to user stories.
1) When implementing a new feature that has some rules associated with it, and you would like to enforce those rules when you introduce that new functionality, you would express the rules as examples that help describe the story. For example from my work as a conference chair:
As A Track reviewer
I want to add reviews
Some of the examples:
Scenario: Unable to review for other tracks
Given “Sam” has created a session on another track
When I try to add a review to that session
Then I should not be allowed
Scenario: Unable to review my own session
Given: I have created a session on my track
When: I try to add a review to that session
Then: I should not be allowed.
Scenario: Unable to review sessions I’m a co-presenter on
Given a session exists on my review track
And I am the co-presenter on that session
When I try to add a review to that session
Then I should not be allowed.
Each of these scenarios is indicating a different rule.
Depending on your definition of ready, you may in fact identify those examples as you are getting story ready for an iteration.
2) When you’ve implemented a feature, and now you are going back in to enforce some rules later, the rule may show up as a user story itself.
For example, let’s say that we have already created the capability of adding a review, but we hadn’t yet enforced the rule that a reviewer cannot review a session on which they are a co-presenter (ok, we probably forgot that one). You may see a user story that says:
“As Reed the reviewer
I cannot submit a review to a session on which I am a co-presenter
So that I avoid a conflict of interest from reviewing my own session.”
Or something along those lines.
Q: Aside from user stories and analysis models, what other analysis techniques are most effective on an agile project when you are dealing with an enterprise wide initiative?
A: Generally speaking the same analysis techniques that are helpful on an enterprise wide initiative that you are not doing in an agile fashion. The specific techniques you use depends more on the nature of the project, the stakeholders, and the organization than on the approach you are using.
I find impact mapping is helpful to initially identify what options make the most sense to help us meet a specific goal.
Story maps are helpful for putting some visual structure to your product backlog so you can easily see how stories relate to specific features.
User modeling is helpful to identify all the users for the system and help determine if you have the needs of those users accounted for.
Otherwise if you have a heavily data intensive project, data models and data dictionaries are helpful.
If your application has a great deal of user interaction, user interface prototypes can be very helpful.
Q: Using agile, how does the PO team figure out what will please the stakeholders?
A: Build something. Show the stakeholders. Get their feedback. Adjust as appropriate. Repeat.
Q: Do you use surveys or interactive models when you are dealing with an enterprise wide project?
A: Use surveys with caution. What people say they will do and what they actually will do is often two separate things. When people respond to survey they may be more likely to say what they think you want to hear, not what they actually think.
It depends on what you mean by “interactive models” and how much work is involved in building them compared to building actual parts of the application that the stakeholders can see (and potentially use) and provide feedback on.
I don’t know that whether an application is enterprise wide or not makes much difference in this case. Your main problem is going to be the complexity that comes with having to satisfy several different stakeholders with potentially very different needs. The best way to address that and keep the project from spiraling out of control is to have a strong decision maker in the product owner role that is keeping the goal of the effort in mind and is always making product decisions based on that, not sub optimizing for the loudest stakeholder – not an easy task.
If you find these answers helpful and thought provoking, please share with your fellow BAs and have them join our conversation!
Also, let me know if there are other questions you have – I am happy to answer!