Tips for Prospective PMPs - Edition 28

Welcome to the 28th edition of Tips for Prospective PMPs. This newsletter provides tips, advice, and lessons for those project managers pursuing the PMP?.

This edition includes an article on an introduction to user stories and access to 5 practice questions and mini-lessons.

Article 1: An Introduction to User Stories

As a project manager, do you encourage your teams to write stories?? If you don’t, you might consider this concept. Not fictional stories but user stories.

User stories can be a powerful technique to begin conversations with your stakeholders about project needs from the users’ perspectives.

User stories are not use cases. Use cases can also be useful for the technical team. User stories are written from the perspective of the user, not the technical team.

The Agile Effect

While user stories have been used for agile projects, they can also be effective for traditional projects. User stories are typically written during the project's initiating or planning phases.

User stories are not intended to be specific business or technical requirements but to frame the user's needs from the user’s perspective.

The best stories will be driven by the why and not by the solution. The solution can be elaborated later in the project process.

Six Tips For More Effective Stories

Consider the following six tips for writing user stories:

1)????? Use the format: AS A (persona or stakeholder), I WANT (What), SO THAT I Can (do something or accomplish something of value - the Why). Example: As a project manager, I want to see the progress of my team members on assigned tasks so that I can effectively support the project objectives.

2)????? Write stories that are user focused NOT technical or solution focused.

3)????? Use the INVEST guidelines (developed by Bill Wake) to determine if the story is usable by the team:

• Independent – the work to realize this story can be performed independently of other stories.
• Negotiable – the story should be open to alternative solutions and should leave room to negotiate the details.
• Valuable – stories need to be valuable to a customer, user, or both. Customers pay for the product. Users use the product.? But it is also ok to have stories that have value for the development team.
• Estimatable – stories should be estimatable by the team designing and building the product. The team should be able to determine the relative size of the story. Avoid large stories (Epics) and stories that are too ambiguous.
• Small – Stories worked on in sprints should be small. For example, if you have a two week sprint, you don’t want a story that takes the full two weeks to develop. Large stories or Epics are good for longer-term planning but eventually need to be broken down into small stories.
• Testable – the team should be able to test whether or not a story passes or fails the required tests.? Being able to create clear acceptance criteria is a prerequisite for testable.

4)????? Consider multiple types of stories (not just for end users):

• Product stories.
• Function and feature stories.
• Business value stories.
• Project management stories.
• Compliance stories (safety, security, other regulatory requirements whether stated or expected)
• Infrastructure stories
• Stories that address internal standards
• Stories for operational departments
• Technical stories
• Other (collaborate with your users to create additional stories)

5)????? Develop acceptance criteria in order to get clarification of the story. Acceptance criteria are the requirements or specifications that must be met before the story can be accepted. Well-written acceptance criteria establish an agreement with the customer. Without specifying the solution, acceptance criteria provide the framework for ensuring that the story has been completed.

6)????? Stories should be developed through collaboration and discussion. Use a non-technical and non-biased facilitator. The facilitator should have a solid understanding of a well-written user story to help steer the collaboration to create usable user stories.

Benefits of User Stories

User stories offer the following benefits:

• Encourage collaboration between the team, customers, and end users.
• Provide a user-focused view of the work and product.
• Focus on the need, not the solution.
• Provide a better understanding of the scope of work.
• Develop relationships with the customers and end users.
• Promote innovation.
• Provide immediate feedback to the development team.
• Improve efficiency.
• Mitigate the risk of delayed feedback.
• Leave room for flexibility in the details of the final solution.

Outside of Agile

User stories are popular and effective for Agile projects.

But can they be used for traditional projects? I believe so and have used them for non-agile projects. Consider the benefits of Agile stories.

Not sure if they will be effective for non-Agile projects? Try them. At a minimum, user stories can start conversations with your customers and end users for the better good of the project.

Eddie Merla, PMI-ACP, PMP

P.S.: If you are preparing to take the PMP? exam, expect to understand the concept of user stories and how they can contribute during the scoping process or through the agile or hybrid life cycles. Know the INVEST criteria and the benefits of user stories.

Article 2: Five Practice Questions and Mini-Lessons

Question #131: Communications channels

Question #132: Communications model

Question #133: Plan risk management

Question #134: Identify risk

Question #135: Qualitative risk analysis

Check out our schedule of upcoming PMP? prep training:

#pmp #pmpprep #pmptraining #pmpcertification

Training Schedule - Certifiably Project Minded (certify-pm.com)

Download our free PDF mini-book: Kickstart Your Journey to PMP? Certification