Defining what work is to be done to develop a feature or iterate on it is to lay out the bounds of what a User will experience and do. Where do they start? Where do they finish? Where does the User get value? Are they doing one of something? a few? many? How does a User create, edit, delete, or retrieve an item? Here is where we communicate all of these things.

User Stories

My approach toward Product Management is to focus on delivering value to a user. Therefore, I utilise User Stories as a general informal statement describing a goal and result from the user's perspective. It has the following structure:

As a [particular type of User], I need/want to [perform some task] so [some value is delivered].

For example:

• As a team member, I want to see a list of my upcoming tasks so I can plan my day.

• As a time-poor dog owner, I need to find someone to walk my dog so that I can do my job without distraction.

• As someone who is hungry after working in an office, I need food that will tie me over until I get home so that I don’t ruin my appetite or consume too many calories.

As I get more specific in the User Stories, then ideation improves in that solutions are smaller, simpler, and more effective. Going through all the other steps, I have written about previously will feed into your stories.

For Project Weeknotes, the User Stories are as follows:

As a person who reviews my week, I need to reflect and plan every week so that I can keep on track with my personal and professional development.

As a person who reviews my week, I need to share that with others so that I have some form of accountability and scrutiny.

As a person who reads a weekly review from someone reflecting, I want to see the last few weeks and get context so that I can help and comment on the current week.

As a person who reads a weekly review from someone reflecting, I want a short and concise overview of what is going on with them so that I can have talking points at a time when we converse that offers assistance, critiques, encouragement, and accountability.

Acceptance Criteria

As software is built, it must reach a set of conditions to be in a state of done. Rather than a list of technical and design instructions, the conditions are from the user's perspective. This is where Acceptance Criteria comes in to help inform all stakeholders on what a piece of work intends to look like. The layout of the Acceptance Criteria is as follows:

Given I am [list of states to explain a scenario] when [list of actions to take] then [list of results that happen]

In the lists, you can start to feel in the right place when continuously writing “and”, “or”, “but”, “therefore”, which indicates your specificity.

For example:

Given I am hungry, it’s late in the evening, and I don’t have time to cook, when I open an app and search in my local area, then I am presented with a list of open restaurants and informed how long they would take to deliver.

Acceptance Criteria serve to give anyone working on the problem the boundaries needed to formulate ideas.

For Project Weeknotes:

Given I am reflecting on the week that just passed and planning the week ahead, when I open the app and select new, then I can type what I have done, what I didn’t do, what I learnt, and what I plan to do.

Given I have reflected and planned but forgotten to add something or made a mistake, when I select an entry and select edit, then I can add, change, or delete anything I have previously created.

Given I want to read someone’s reflections on the week when I go to the app, then I am presented with this week’s reflections and planning, and when I scroll past it, then I can see the previous week … and so on.

End of Part 5

From here, I have everything I need to ideate and start to define what the work will look like. I sometimes agonise over everything in parts 1-5 of this scoping series to get it to a point where people react in a way of thinking, discussing, and collaborating. This will involve going out and talking to people, desktop research in online communities that match the persona in question, surveys and questionnaires, etc. Sometimes I will take a step back and scope something that will contain a flow that will offer insight into the piece I originally started.