SAFe

Learning Agile principles through SAFe

Demystifying OKRs: Understanding Object Key Results and When to Use Them

If you are a business analyst, product owner or a team leader, you’ve likely come across the term “OKR” or “Object Key Results.” But what exactly are OKRs, and how can they help your organisation achieve its goals? In this article, we will demystify OKRs and shed light on when to use them as a powerful goal setting framework. What are OKRs, A.K.A Object Key Results? OKR stands for Object Key Results. It is a goal setting methodology that was popularised by companies like Google and Intel and has been adopted by numerous organisations across different industries. OKRs are designed to align teams and individuals towards a common set of objectives, providing a framework for setting ambitious goals and tracking progress. At its core, an OKR consists of two main components: the Objective and the Key Results. The Objective is a clear and aspirational statement that defines what you want to achieve. It should be inspirational and provide a sense of purpose, motivating teams to strive for excellence. The Key Results, on the other hand, are measurable outcomes that indicate progress towards achieving the Objective. They serve as quantifiable milestones that help teams track their progress and determine if they are on the right track to achieve their Objective. OKR Framework Template There are several ways how OKRs can be implemented, but here is a tweaked OKR template inspired by the template defined by JIRA’s confluence app. What Are Some OKR Examples? For example, let’s say you run a scrum team, and your Objective is to remove user journey’s UX impairment. Your Key Results could include metrics like “Replace drop down filters with react mobile horizontal menu“, “Use react to add mobile gesture support on the desktop version of the site” and “store user session data for when the user comes back.” These Key Results are specific, measurable, and time-bound, making them effective in guiding your team towards achieving the Objective. When Should You Use OKRs? So, when should you use OKRs? Here are a few scenarios where OKRs can be particularly beneficial: #1. Goal Alignment OKRs are ideal for aligning teams and individuals towards a common set of goals. When everyone is working towards the same set of Objectives and Key Results, it creates clarity and ensures that efforts are focused on achieving the organisation’s priorities. #2. Ambitious Goal Setting OKRs encourage setting ambitious goals that go beyond the status quo. By setting stretch goals, teams are motivated to push their limits and strive for excellence. #3. Measurable Outcomes OKRs emphasise measurable outcomes, which help teams track progress and determine if they are on track to achieve their goals. This data-driven approach enables organisations to make informed decisions and take corrective actions if needed. #4. Flexibility and Adaptability OKRs are designed to be flexible and adaptable. They can be set and revised periodically, allowing organisations to respond to changing circumstances, market dynamics, or business priorities. #5. Employee Engagement and Accountability OKRs promote employee engagement as they provide a sense of purpose and ownership. When employees are aligned with the organisation’s goals and have clear Key Results to work towards, it fosters accountability and empowers them to take ownership of their work. In conclusion, OKRs are a powerful goal setting framework that can help organisations align teams, set ambitious goals, track progress, and foster employee engagement. By defining clear Objectives and measurable Key Results, organisations can create a roadmap to success and drive results. So, consider incorporating OKRs into your goal-setting process and unlock the full potential of your team and organisation.

Demystifying OKRs: Understanding Object Key Results and When to Use Them Read More »

user stories

What Are User Stories?

Section #1. What are user stories? Talking about the different story types and giving real world user story examples. We will look at how sub-tasks are such an integral part to resolving user stories and how to write great sub-tasks Section #2. Questions about User Stories Who is responsible to write user stories? When do we write user stories? Let’s find out together in section 2. Section #3. Planning User Stories How do we plan user stories to get the best value result? What is story mapping and how can it help us plan priorities better? Section #4. The relevance shift Talking about the shift in priority relevance. A priority can lose its relevance without losing its priority level Section #5. Why User Stories? Why would you need to work with user stories? How can user stories help you be more efficient in achieving sprint goals Section #6. Resources & FAQs Download here the document for SEO measurements taken to improve ranking of this article. FAQs about user stories. What are user stories? User stories, as the name implies, are pieces of information that indicate a user centred requirement that when put together, will form a new system behaviour of the end product. A user story is an integral part of the product backlog, team backlog and the sprint board. Simply put, companies need to make money, and for that to happen, business analysts, sales and many other stakeholders need to communicate the requirements to the scrum teams. Companies make use of known communication systems to effectively communicate requirements and secure timely delivery in adherence with the original request. The ideation of user stories comes from the need to create a more informal communication that is actionable in an estimable amount of time. Basically, what worked in the past has no place in the ever changing, ever growing present. Depending on the type of venture or enterprise, business requirements and KPIs can change in such a way that would require companies to be flexible and adaptive to create the best competitive advantage in their industries. What makes a user story great? As Bill Wake puts it, a great user story follows the INVEST model Let’s break down this user story! ‘As a user…‘ The story starts with these words. Here, the team had decided to use the ‘user’ term only to refer to the end user. The user could also be an administrator or a developer or a stakeholder such as marketing or sales. Identifying the right user would allow the team to develop the requested functionality and create user tests. This user story meets the DoR (definition of ready), because it follows a format that ensures complete information for converting the story into technical requirements. ‘I want…‘. These next words indicate to the team what the user wants to be able to achieve, and here is where the team looks for a specific goal that the user wants to be able to achieve which would complement the overall user experience. In the example provided, the user would like to be able to set custom market movers parameters so that they can have a personalised watchlist of the trade-able instruments that are causing change in markets. ‘So that…’. This is an integral part of the conversational user story format as it indicates the monetising reason to satisfy the user needs. What will the user get from achieving their goal? What does it mean for the business? It gives an immediate understanding of why building the feature part of the user story is profitable for the user and the business. In the example above, the user wants to be able to take advantage of short term trading (A.K.A swing or day trading). Market movers filters can help the user do this by eliminating missed opportunities on trending markets. The above mentioned user story format aids the scrum team to convert stories into technical requirements. Technical requirements need to be specific for the team to understand what exactly they need to build. The above user story structure ensures information is correct and complete, however you may notice that the user story is not technical and specific enough to be able to create a proper technical requirement. The user story asks for custom movers for the users of the app, so that they can create a list of instruments that fall under their interested trends. However, user stories are not technical. This means that sometimes, teams need to break down a user story into sub-tasks. How do you build subtasks? Well subtasks are usually more technical pieces of information than a user story. They are the breakdown of user stories that represent the amount of effort a team will take to achieve the parent user story. Through the many years working as a product owner, I’ve seen many scrum teams struggle writing qualitative subtasks. Well here’s how we made our subtasks great! #1 A subtask should resolve one or more acceptance criteria defined in the user story. If it’s not resolving at least one acceptance criteria, there’s a high chance your sub-task is irrelevant to its mapping. Keep building subtasks until you have a subtask for each acceptance criteria, you don’t need more, and you must not have less. #2 We wrote test scenarios for each user story. Test scenarios, allow the scrum team to test their work from a user perspective. That’s all there is to your subtasks and you can use any format for them. Below is how we broke down the subtasks for the example above. Notice how we always looked for ways to improve visual communication. We used square brackets at the beginning of each subtask so that the scrum team members can quickly visualise their responsibilities: From the screenshot above, you can see that for this particular user story, we had a subtask for each acceptance criteria and an extra subtask to request the designs from the design team. The scrum team measures user story achievement through

What Are User Stories? Read More »

acing the product owner role

The Product Owner (PO) role. Key Strategies For Success.

In This Article #1. This isn’t your job, stop worrying about it! #2. Feature Requisites, A Break or Make! #3. Understand The Customer #4. Define Clear Product Vision And Strategy #5. Collaborate Effectively #6. Prioritise Ruthlessly #7. Embrace Agility #8. Communicate Effectively #9. Measure Success #10. Be A Problem Solver As we may well know by now, the product owner role is an emerging job post that has found its roots in the grounds of Agile, a methodology that is set to improve the efficiency and quality of organisations through the Agile Manifesto. Some of you may confuse the role with that of a scrum master role or even a project manager… what the heck! Some of you may even have never heard of it, but the role of a product owner is an essential part of organisational processes and focuses on specific targets. Let’s take a quick peak at these targets one by one! #1. This isn’t your job, stop worrying about it! When joining a company as a product owner, it’s easy to slip into the common mistake of thinking that you are asked to take a managerial role for the product you are supposed to run, but managing processes is a whole different beast which requires another full time role like a Product manager, technical lead (techlead) or a scrum master, depending on the requirement. If you were to slip into such mistake, you will probably be of no good to the company or your success in the role. First things you need to learn? Is what am I expected to achieve in the product owner role? There are three tips that I can give you in order for you to nail the answer to this question, and here they go. You’re The Interviewer The company you are to work for is not merely interested in how you will do with answering the interviewer’s questions, they’re interested in analysing the questions you have prepared for them too. Let’s say it right away, the fact that you prepare questions for your interview is already a big plus for you, as many, barely have any questions to ask and the few that do, have only questions which the companies are used to hear: What benefits you offer? how much is the salary? etc… But the questions you ask will not just determine your success in the interview, they will also define your success or failure in the role going along, depending on what you ask. There are many questions one may ask to unveil the path to success in a role. However, one particular question that does just that is to ask for two or three main goals one should achieve in order to be successful in the role as perceived by the company/interviewer. Asking what the key goals are would potentially give you a path of work prior the first day at work. And while you are at it, why not ask the 3 things that led to failure in the previous role. This will give you 3 things to shift away from when starting your job. Understand The Quality Of The Role There really isn’t a one size fits all description of the role and responsibility of a product owner. Companies may hire you for a role of a technical, financial, CRM or even marketing product owner. Indeed they do fall under the cap of product ownership, but they bring along their own set of responsibilities and day to day tasks. What better way to excel in a product owner role then knowing that your managers want you to handle the CRM part and not focus on the technical part. Although product ownership comes in colours, we do find a common understanding of what a product owner should aim for. The explanation goes deep, however we summarise this in one quote. A product owner is there to leverage the value of the end product, they do so by focusing on the validity and timeliness of the input and output in the software development lifecycle #2. Feature Requisites, A Break or Make! Wether its a top-down or a bottom-up feature request, you need to properly document it to make sure you leave no stones unturned and no holes. Let’s face it documentation is a struggle in all modern agile teams. Tools like JIRA help every actor in the feature delivery cycle document just enough to for handshaking and engine starting. Hand Shaking With complete task reporting, the product owner is able to communicate and agree both with stakeholder and developers that the priority is desired and actionable. This in turn becomes a bullet proof ritual that the product owner practices to ensure correctness, workflow and most importantly continuity. Engine Starting Properly requesting a feature will get the software development life cycle engine to start. Scrum teams will either be able to fully understand it or ask the right questions. An incomplete feature request will lead to scrum team members to go back and forth for clarification and information needed in order to turn the task into a technical requirement, or not action it at all, leaving it to the PO to come back and prioritise it instead of doing their job for them. How Do You Request A Feature? Well, let’s take a quick look back. We said that the product owner needs to perform two important tasks in order for their feature request to be a success. Handshaking with all relevant stakeholders, and engine starting for the scrum team. There are several tools at hand that a product owner can use to deliver feature requisites. Here are some of the strategies that I would use in different scenarios. One Requester, One Stakeholder Scenario This is what I like to call a domestic feature requisite. In these scenarios, the requester is usually also the stakeholder themselves. Whenever this is the case, keeping it simple is the best way around. As we have the advantage of having all

The Product Owner (PO) role. Key Strategies For Success. Read More »

Scroll to Top