There are many approaches that a business analyst can use to capture requirements. Depending on the working environment, the methodology used and several other factors, it can be really challenging to figure out what technique would be most appropriate.
In part 7 of The Knowledge Brief™ we look at business requirements and stakeholder requirements, this post is to clarify Use Case, User Stories and Job Stories approaches to developing requirements, along with my personal recommendations.
What are Use Cases and Scenarios?
Image BABOK® Guide 10.47
Essentially a Use Case is a thinking process. When you think about a Use Case, you are considering how the user and the system interact. You're also considering where variations can occur, where exceptions can occur, what must be true before the user can even begin the requirements in the path, and what must be true after.
Use Cases describe how the main actor, the solution, and any other needed actors interact. Use Cases are usually started by the main actor, but some methods allow another system, external event, or timer to do so. A Use Case describes what could happen when someone tries to achieve a goal with the solution. It shows primary and alternative flows. Primary flow is the quickest way to reach the Use Case goal. Alternative or exception flows describe situations and problems that prevent use case completion. Use Cases are written from the actor's perspective and don't discuss solution internals. In the process of going through that, you frequently discover questions that you don't consider when you're writing a requirement here, a requirement here, a requirement here, or a huge, long list of requirements.
Title ... Actor ... Scenario
Pros of Use Case
- Use Case diagrams can help define the scope of a project and give a high-level idea of what it needs to do.
- Stakeholders can easily understand use case descriptions because they flow like stories.
- By including a desired goal or outcome, the business value of the Use Case is made clear.
- Use Case descriptions explain how a system is supposed to work.
Cons of Use Case
- Because the format for use case descriptions is so flexible, information that would be better captured with other methods, such as user interface interactions, non-functional requirements, and business rules, may be put into use case descriptions.
- Decisions and the business rules that define them shouldn't be written directly into use cases. Instead, they should be managed separately and linked from the appropriate step.
- Because Use Cases are written in a flexible way, they may include details that aren't relevant or aren't needed in order to show every step or interaction.
- Use cases don't have anything to do with how the solution is designed on purpose. As a result, it may take a lot of work during development to map use case steps to software architecture.
- Some people may assume you are jumping ahead towards a solution.
Use Case vs User Story?
When you working to understand what requirements, acceptance tests, and acceptance criteria should go in each of these large, long lists of product backlog items, it can be overwhelming. This is the value of the Use Case, and it is why, even as we move towards more agile environments, it can be beneficial to learn the skill. There are two commonly used formats to describe an application. One is called a Use Case, and the other is a User Story. In this video, Geekific talks about both Use Case and User Stories, and then expand on how we can design or draw these Use-Cases.
Personally I find Use Case quite hard to read and the lines moving back and forth seem to be complicated. I think, as business analysts are essentially the conduit of information, it may be more beneficial to get stakeholders to draw what they are wanting with the guidance of the BA.
What are User Stories?
User Stories are all about the why, what and the who. User Stories are non-technical explanations of features written from the perspective of the end user. User Stories, as opposed to functional or non-functional requirements, use non-technical language to provide context to development teams. Rather than just a technical scope of work, the goal is to understand why the feature is required and its value to users.
During the sprint planning meeting, product managers write user stories, and the team decides which stories to tackle. In addition, teams can use planning poker or other strategies to estimate the difficulty of User Stories. This makes it easier for the team to ensure that their story commitments can be met realistically during a sprint.
As a (who) I want (what) so that I can (why)
Pros of User Stories
- Easy for all parties involved to understand.
- There are different ways to find out what people want.
- Puts the value of stakeholders first.
- By working together to define and explore User Stories, we can learn more about the business domain as a whole.
- Bound to small, testable, and easy-to-implement pieces of functionality, which makes it easy to deliver quickly and get feedback from customers often.
Cons of User Stories
In general, User Stories are meant to be a short-term tool for capturing requirements and figuring out which ones are most important. They are not meant to help people remember information or give a detailed analysis. If you don't follow this rule, the following things can happen:
- This conversational way of working can be hard for the team because they don't know all the answers and specifics right away.
- Needs context and visibility; the team can lose sight of the big picture if stories aren't traced back through validation or added to with higher-level analysis and visual artefacts.
- May not provide enough documentation to meet the need for governance, a baseline for future work, or stakeholder expectations. There may be more documentation needed.
What are Job Stories?
Job Stories, like user stories, are an excellent way to gather requirements. They are particularly useful in an agile environment, where one of the key values is responding to change rather than sticking to a plan. They are used to represent an item in the product backlog (also known as a PBI) or a requirement in terms of a job that needs to be completed by a stakeholder. Job Stories provide more context for the user's situation, allowing the team to share their perspective and create a solution for what the user wants to do. They pay attention to the motivation of the stakeholder and try to provide as much context for the stakeholder's motivations, anxieties, and struggles.
When <situation> I (who) want to <motivation> so I can (why) <expected outcomes>
When someone <situation>, actor(s) <motivation> so that <expected outcomes>
In this video by Clayton Christensen, he describes why Job Stories are potentially a better option than User Stories.
Pros of Job Stories
- This format reduces assumptions regarding the role and removes the persona biases
- It can be set up for cause and effect scenarios (as seen in part 4 of The Knowledge Brief)
- This format focusses on stakeholder motivations instead of defining implementation
- It is helpful for UX design
Cons of Job Stories
- Teams typically find it easier to empathise with the stakeholder(s)
- Removes focus on features and instead focuses on the stakeholder's desired future state
- Teams can use Job Stories and User Stories together on backlog. The Job Stories indicates the motivation and outcome for the stakeholder, while the User Story indicates features that could solve the problem and this can create confusion.
User Stories vs Job Stories?
So, while Job and User Stories each have their own strengths, they can be combined to provide both benefits in a single story that will go into the backlog. I won't go into the pros and cons of this as I am sure you can decide for yourself. In this video User Stories and the Alternatives, by Scrum Inc the author explains that all we actually require in our projects are five items.
- We need a value proposition because we want to make sure that whatever we're doing is valuable to someone
- we need a recipient of that value
- we need an action needed because people are doing stuff
- we need to know our constraints and
- we need the testing criteria.
When you have all of this, you don't need any specific format, but you do have to satisfy this because the people making your stuff have to know
- who it's for,
- why it's there,
- and what constraints they live in
The important thing is that everyone knows the vocabulary and understands the level of granularity at which the vocabulary is at, and then how you phrase those those work items has to meet these these criteria. It does not have to be in any particular format; the templates we have are simply convenient methods that have been used frequently, and people are very comfortable with them.
Don't be afraid to do a simple mashup, it's all about what your team needs to get the job done.
(When) <situation>, as a (who) I want to (what) so that (why).
Conclusion
Simply there is no right or wrong answer here (the type of answer I don't like). The most important thing seems to be figuring out what works best as a source of information—a way to share not only what needs to be done but also why and the context that the team, and especially the people doing the work, need to get it done well, right, and fast.
My recommendation is that business analysts master one technique before moving on to others. The most obvious would be User Stories, which are tailored to the needs and requirements of the stakeholders (part 5&7 of The Knowledge Brief). A Use Case will help you understand the context of the current or future state (part 6&8 of The Knowledge Brief). When developing solution requirements (part 8 of The Knowledge Brief) and root cause analysis (part 4 of The Knowledge Brief), Job Stories could be more useful than User Stories.
Post a Comment