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 »
Real life examples of product ownership in agile
Between learning about Agile and scrum and applying it in real world scenarios the beast has a totally different form. Discover all about real world challenges that Agile teams face.
Real life examples of product ownership in agile Read More »
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 »