In the dynamic realm of product development, articulating requirements effectively is paramount. The User Job Story (UJS) format offers a nuanced approach. It blends the strengths of traditional User Stories with the contextual depth of Job Stories. This method enhances clarity and aligns development efforts with genuine user needs.
Understanding the User Job Story Format #
The UJS format is structured as:
As a [role], when [a situation], I want to [an action], so I can [expected outcome].
This structure integrates the user-centric focus of User Stories with the situational context emphasized in Job Stories. By specifying the role, situation, desired action, and expected outcome, teams gain a comprehensive understanding of user motivations and the problems they aim to solve.
Advantages of Combining User and Job Stories #
Traditional User Stories follow the template:
As a [type of user], I want to [an action], so that [a benefit].
While effective, this format can sometimes lack contextual depth. User Job Stories, on the other hand, emphasize context and motivation via a situation:
As a [role], when [a situation], I want to [an action], so I can [expected outcome].
By merging these approaches into the UJS format, teams gain from:
- Enhanced Contextual Understanding
- Incorporating the situation provides clarity on the circumstances prompting user actions.
- Clear User Identification
- Specifying the role ensures that development efforts are tailored to the appropriate user segment.
- Focused Outcomes
- Highlighting the expected outcome aligns the team’s objectives with user goals.
This comprehensive perspective aids in developing features that resonate with users’ real-world scenarios.
Sourcing User Job Stories #
Precise UJSs are derived from various channels:
- Market and Competitive Research
- Analyzing industry trends and competitor offerings reveals gaps and opportunities, informing potential user needs.
- Customer Development
- Engaging directly with users through interviews and surveys uncovers insights into their challenges and desires.
- Sales and Customer Success Engagements
- Feedback from sales teams provides firsthand accounts of customer pain points and feature requests.
Collecting UJSs from these sources ensures that the product backlog reflects genuine user pains, enhancing the product’s market fit.
Prioritizing the Feature Backlog #
A well-prioritized backlog is crucial for effective product development. It ensures that the most valuable features are developed first, optimizing resource allocation and time-to-market. Prioritization helps in:
- Aligning with Business Goals
- Focusing on features that drive strategic objectives.
- Maximizing User Satisfaction
- Delivering functionalities that address the most pressing user needs.
- Efficient Resource Utilization
- Allocating development efforts to areas with the highest impact.
Neglecting prioritization can lead to resource wastage and delayed product releases.
Implementing SCRUM Poker for User Job Stories Prioritization #
SCRUM Poker, also known as Planning Poker® (registered trademark of Mountain Goat Software). It is a consensus-based technique mostly used to estimate the effort required for backlog items.
Participants estimate effort by placing numbered cards face-down on the table instead of announcing them aloud. Once all cards are revealed, the team discusses the estimates. This method mitigates the anchoring bias, preventing early estimates from unduly influencing subsequent ones.
In our approach, we will show how to use SCRUM Poker for UJS’s business value prioritization based on Value, Urgency and Risks.
Steps to Conduct SCRUM Poker #
Here’s a quick rundown of the main steps for playing SCRUM Poker.
Step | Description |
---|---|
Preparation | Each participant receives a deck of cards with values representing effort estimates. In our case they would be Value, Urgency and Risks. Typically estimates follow the Scrum estimate cards (0, %, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?) or other types of sets (see below). The values represent the number of story points, ideal days, or other units in which the team estimates. |
Discussion | The Product Owner presents a User Job Story. The team discusses its details to build a shared understanding. |
Estimation | Each team member privately selects a card representing their estimate for the story’s effort. |
Revelation | All participants reveal their selected cards simultaneously. |
Discussion | If estimates vary, team members discuss their reasoning. This process repeats until a consensus is reached. |
Using Firepoker App for SCRUM Poker #
Firepoker (firepoker.app) is a simple online tool for conducting remote SCRUM Poker sessions. To use it the Product Owner hosts a new game and shares the link with participants.
Step 1: Create a Game #
The Product Owner or other team member hosts a new game and shares the link with participants.
- Fill in the Names: Add host’s name (what other team members will see) and the name of the Game.
- Add User Job Stories: The Product Owner inputs the stories into the game. If you want to use Value/Urgency/Risks estimation, add the same story for each category. Firepoker app does not support it automatically.
- Choose the set of estimate cards you want to use.
- Scrum: 0, %, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ?
- Fibonacci: 0, %, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 and ?
- Sequential: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and ?
- Hourly: 0, 4, 8, 16, 24, 32, 40, 60, 80, and ?
- T-Shirt: XXS, XS, S, M, L, XL, XXL and ?
- Press “Create game” button.

Step 2. Play the Game #
Invite Players
- Copy the address in your browser and share with team members.
- The ideal group size for SCRUM Poker is 3–9 participants. It is the recommended size of a Scrum team (Scrum Inc. Glossary).
Select the Story for Voting
Firepoker supports 2 types of stories:
- Structured in User Stories format, and
- Free-form stories.
Story list tab shows all created and imported stories.



Voting
After the host selects a story for voting, each player privately picks an estimation card. Then, they vote three times for each story, estimating its value, urgency, and risks. Participants don’t see others’ results during the voting.

Reveal and Discuss
- Once all votes are in, players discuss variations in estimates. The team either reaches consensus or can accept, e.g., the average estimation score.

Finalize Scores
- After accepting, the final scores are recorded in the backlog.

Step 3. Business Value Prioritization Table #
Once the final scores are recorded in the backlog, the Product Owner fills in the Prioritization Table. It calculates the final Weighted Score. When it’s all sorted, you’ll see the prioritized backlog.
Theme | Epic | User Job Story | Value | Urgency | Risk | Business Value Weighted Score (V+U+R) |
---|---|---|---|---|---|---|
User Authentication | Social Media Login Integration | As a new user, when registering, I want to sign up using my social media account so I can quickly access the platform without creating a new username and password. | 18 | 5 | 13 | 36 |
Multi-Factor Authentication | As a security-conscious user, when logging in, I want to enable multi-factor authentication so I can enhe protection of my account. | 40 | 8 | 60 | 108 | |
Password Recovery | As a returning user, when I forget my password, I want an easy recovery process so I can regain access to my account without frustration. | 40 | 5 | 20 | 65 |
Step 4. Estimate Efforts #
Once you have each User Job Story (or feature) ranked by business value, the next step is to estimate the development effort. Here’s how to conduct it with Scrum Poker:
- Gather the Team: Include everyone who will help implement the feature (developers, QA, etc.).
- Present the Story: Briefly restate the User Job Story so the team clearly understands the goal and scope.
- Discuss Unknowns: Ask questions about dependencies, risks, or missing details. It is important everyone understands what “done” looks like.
- Vote with Cards: Each team member privately chooses a card with a number that reflects their estimate for the amount of effort needed.
- Reveal and Align: All estimates are revealed simultaneously. If there is consensus, that estimate becomes the story’s point value. If not, people with very high or very low estimates briefly explain their reasoning. The team revotes until you converge on a single final estimate.
This collective estimation process helps uncover hidden complexities and creates more accurate (and agreed-upon) story point values for every feature. It also builds shared ownership, because all contributors shape the effort estimate together.
Step 5. Calculate Total WSJF #
With business value (or other priority metrics) and development effort both in hand, you can compute Weighted Shortest Job First (WSJF) to see which stories deliver the highest ROI per unit of effort. A common formula for WSJF is:
WSJF = Business Value ÷ Job Size
- Business Value: How valuable is it to the user or the business?
- Job Size (Effort): The Scrum Poker estimate representing how big the story is (in story points aligned with Value points).
The resulting ratio (often a decimal) tells you which features deliver the greatest overall impact per point of development effort.
Example:
Theme | Epic | User Job Story | Weighted Business Value Score (V+U+R) | Job Size – Tech Effort Estimation | Total WSJF Score |
User Authentication | Social Media Login Integration | As a new user, when registering, I want to sign up using my social media account so I can quickly access the platform without creating a new username and password. | 36 | 3 | 12.0 |
Multi-Factor Authentication | As a security-conscious user, when logging in, I want to enable multi-factor authentication so I can ensure protection of my account. | 108 | 8 | 13.5 | |
Password Recovery | As a returning user, when I forget my password, I want an easy recovery process so I can regain access to my account without frustration. | 65 | 5 | 13.0 |
Compare this to other features: higher WSJF means you should generally implement that item sooner. It is “multi-factor authentication…” story in our example above.
In practice, you might also consider intangible factors like strategic fit or brand impact, but the basic WSJF framework keeps you grounded in data.
Putting It All Together #
Steps 1 to 5 bring business and technical structure to your prioritization:
- First, you’ve identified and ranked User Job Stories by business value (Steps 1–3).
- Second, you anchor them with realistic effort estimates (Step 4).
- Finaly, prioritize your backlog based on the WSJF ratio (Step 5).
This ensures you tackle the highest-impact items first without overcommitting your team.
Pros and Cons of SCRUM Poker #
Understanding the advantages and limitations of SCRUM Poker helps teams decide when and how to use it effectively. While it fosters collaboration and rapid decision-making, it also introduces some challenges that teams should consider. Below is a breakdown of its key strengths and weaknesses.
Pros | Cons |
Inclusive Decision-Making | Subjectivity |
Encourages participation from all team members, fostering diverse perspectives. | Estimates are based on individual perceptions, which can vary. |
Rapid Consensus Building | Limited Quantitative Data |
Facilitates quick agreement on estimates through structured discussion. | Relies on team experience rather than empirical data. |
Enhanced Accuracy | Potential for Groupthink |
Combines multiple viewpoints, leading to more precise estimations. | Dominant voices might influence others, leading to less critical evaluation. |
Have you used the User Job Story format in your product development process? What challenges or benefits have you observed? Share your thoughts in the comments!
For more insights on product strategy and agile methodologies, subscribe to our newsletter today!
Leave a Reply