This post is based on learning content I created for a course about agile management for a learning platform. I have the rights to use this content for my blog.
The worst part was making sure that the texts did not contain any plagiarism. In our digital world, it’s almost impossible to write something that someone else hasn’t written as well.
But I managed to write every test with zero plagiarism. But that took blood, sweat and tears. I’ll leave out my swearing 😉
The mindset of a product owner
According to the agile framework Scrum, the development team is responsible for the creation, i.e. for HOW the software progresses from the idea to the iteration. But the role of the product owner determines WHAT is completed. And it is very important to explain the WHY.
What is the value for the customer, the end user?
If the software development cycle were a ship’s crew, the development team would start the engine, drop the rigging and adjust the mast, while the product owner steers the ship.
The sole aim of a Product Owner is to fully empathise with the target users of the solution to determine the purpose and vision for the software being developed. The Product Owner must understand the customer problem in order to chart the course for the development of the solution.
Project focus vs. product focus
There is a significant difference between the Agile Product Owner role and roles that are more project management orientated. Ideally, the Product Owner is involved in the software development process to guide, instruct, answer questions, validate and, to a lesser extent, help with organisational tasks.
Time must be scheduled into the Product Owner’s daily routine to think holistically about future improvements and further development of the solution. He/she must constantly stay in contact with the users of the product, interview them and adopt their way of thinking during testing and validation.
Product owners ask weighty questions to assess what users need and how the solution being developed can help them meet those needs.
5 questions that agile product managers ask before a project
- Who will use the product?
- What needs/pains will the solution satisfy?
- Which features are crucial for users and how can they be translated into functions?
- How will the product differ from other market offerings?
- What is the timeframe and budget for the launch and commercialisation of the product?
The questions a product owner asks change as the project matures.
Over time, they become more tactical and focus on information and team management in order to achieve the desired goals.
4 questions that agile product managers ask during a project
- How should the product development team be held accountable if the scope or timeline of the project is so late that it has a significant impact on the business?
- How can sufficient meaningful information be provided to the development teams to ensure they understand the development tasks in general before they start working on them?
- How should product owners be involved in product and acceptance testing?
- Is it possible to change the direction of the team if the market changes significantly? (Agility is absolutely necessary here)
How an agile product owner should think
Product owners have the task of listening to the voice of the user and making decisions during product development that prioritise the most important functions and offer them to the audience first. However, it is important for all roles to adopt this consumer-centred mindset and put themselves in the user’s shoes.
Keep an eye on the market, your customers and users
Encourage your product owners and team members to talk to users regularly. It is especially important for product owners to monitor their movements and processes to familiarise themselves with their frustrations so that they can be included as priority items in the development roadmap.
Take, for example, a nurse.
Reading a letter describing the difficulties nurses face in navigating a range of technologies while interacting with a patient represents one level of understanding. However, seeing in real time how a nurse struggles to enter data into a computer and read off an iPad while reassuring a patient in pain creates a more vivid picture that sharpens understanding and gives new meaning to the solution being developed.
By empowering your development team to understand customers intimately and focus on the challenges that exist, product owners can present rough drafts to the team with a clear conscience, knowing that they will be able to execute. The time you invest in educating the frontline team gives them the licence and perspective to come up with creative and time-saving solutions.
If mistakes are made, they can be corrected in subsequent iterations or iteration reviews. In this way, answering ‘questions’ during reviews saves churn in the long run. Experience shows that the time spent on corrections or additional information to realign development and prevent misunderstandings generally takes 5-10 hours per week.
Identify problems immediately
Product owners have learnt to raise their concerns as soon as they review the development. If the time required to resolve the issue is minimal, the problem can be fixed this way without increasing the scope of future development.
Sometimes the adjustments are not so simple. These can be ‘bought’ in the next sprint, which takes two to four weeks. When it’s time to reprioritise for the next sprint, keep an eye on the users. You may find that there are other, more important stories to create.
Product owners record these requests in the product backlog. Similar to the other process-oriented documentation in Agile, you should view record keeping not as an obligation, but as a means to maintain transparency and control.
Focus on the product and not on the project
Product owners are responsible for the entire depth of a solution – from the vision and roadmap to release, sprint and daily planning. Despite the many details that product owners help manage, they keep the big picture in mind.
Focusing on the product means creating clearly defined personas and communicating them to the team so that everyone better understands the product vision and how the prioritisation decisions made contribute to its implementation.
Accept that Agile does not create an initial blueprint
Certain aspects of the Agile process can complicate the introduction and implementation of Agile in large organisations. In particular, the lack of an upstream ‘design and planning’ effort makes it difficult to provide the basic information a company needs before stakeholders can agree to fund a programme. How much will it cost and how long will it take? Business owners need to sell ROI (return on investment) to their boards and other stakeholders, and usually the value of a project idea can only be assessed in the context of time and money.
As Agile does not provide explicit cost and time information upfront, there are also no explicit requirements – these can change as the solution develops.
This causes a lot of anxiety for internal/external customers because they don’t see that the PO has committed to building what they need, or because they don’t see enough detail to be sure that what has been promised will meet their needs.
In either case, we know that claiming to have all the answers up front only leads to a ‘common fiction’. The best approach is to acknowledge the shared risks you are taking with loose parameters for cost and schedule that include viable alternatives, and then let the team use the agile process to achieve those goals.
This is where the concept of Minimum Viable Product really starts to take hold. But then there also needs to be a commitment to future versions that go beyond the MVP, or everyone will push for their favourite features to be included in the MVP.
Create cooperation
With the widespread introduction of the agile framework Scrum, new process-orientated requirements are being placed on the role of the PO, further restricting the amount of time spent and leading to the former 40-hour week turning into a 50-60-hour week.
Before agile, product owners analysed sales targets, supported sales with implementation and even helped with problems with customers. In addition, product owners led the development, communicated the vision, gathered input and created a roadmap for the further development of the product.
Product owners have to take on a number of new tasks – they have to guide ideas and artefacts through the agile lifecycle. Product owners are asked to participate in sprint planning and sprint review sessions and accept or reject the deliverables created by the team. Many also participate in the daily stand-ups.
As Product Owners are asked to look at the improvements in the backlog, maximise the value of the product and organise the backlog, they are very familiar with the scope of the product and the capacity of the team.
When the team loses its Scrum Master, there is often a temptation to transfer the role to the previous Product Owner. Avoid this. Overloading an already full role puts the project at risk and pulls the Product Owner away from exploring challenges, asking the right questions of users and prioritising business value, and instead focuses on managing the bandwidth and organisation of the team.
- Distribute development projects across multiple groups to focus the PO’s attention and increase the time needed to work with Scrum teams.
- Encourage the owner, who is responsible for managing business solutions, to give the development teams the freedom to create and review solutions rather than controlling the process. This way, the team can come up with creative ideas that the PO hadn’t thought of.
- Create a test environment where all builds are encouraged and POs can test at will.
- Communicate the acceptance criteria to the testers. Empower your quality team to act as a proxy for the product owner to take some of the communication burden.
An important facet of New Work is enabling. As a PO, the team should be empowered to take on tasks, develop their own ideas and make their own decisions at the request of the team. This signals trust and appreciation and, in turn, strengthens the team’s self-confidence, motivation and creativity.
Not project- but product-related
The Product Owner plays a central role when it comes to the product. On the one hand, he/she is responsible for supporting the
On the other hand, it is his/her task to write the requirements in the form of user stories in such a way that the requirements are 100% understood by the entire team.
It is also his/her task to continuously optimise the value of the product so that the customers get the greatest possible benefit and support from the product.
In order to achieve this goal, a lively exchange with experts and end users is necessary to gain a deep understanding of the needs, requirements and wishes.
The Product Owner is there to facilitate the realisation of the vision through active action.
The Product Owner is not a team/project manager. He/she also does not have the authority of a team/project manager. A Product Owner is the Product Manager. The team member (in Scrum there are no positions, but roles. I prefer
responsibilities) is responsible for deciding which features are completed in which order, to be finalised. Thus, the product owner is the one who decides on the product.
The development team in Scrum is self-organised and decides which and how many features the team can complete during a sprint (2-4 weeks). As teams in Scrum are, ideally, interdisciplinary, the team decides among themselves who takes on which tasks.
The product owner supports the team and trusts that the team will complete the features it has committed to during the sprint in order to increase the value of the product and satisfy the customer.
Scrum Events Product Owner
Sprint Planning
During sprint planning, the product backlog (PBL) is discussed and the developers decide which user stories will be most useful and valuable in the next sprint. The product owner and the development team do this together by agreeing on an overarching sprint goal and selecting relevant backlog items that will help them achieve this goal.
A sprint goal: The sprint goal consists of one or two short sentences that define the overall goal for the sprint. The goal is to deliver a working product (update) with improved functionality that solves a specific problem for customers (also known as an increment).
The sprint backlog: The sprint backlog is the place where all user stories and tasks are listed from which the team has collectively committed to fully develop them during the upcoming sprint. Based on the Acceptance Criteria and the Definition of Done (DoD).
What is the value of sprint planning?
Sprint planning ensures that teams have enough direction and structure to know what to work on next. The event eliminates the need for long-term plans, which are often inflexible and unrealistic or become obsolete due to changing customer and business requirements.
Teams increase the chances of achieving valuable product improvement during the sprint when tasks are linked to a meaningful sprint goal during sprint planning.
Conducting sprint planning also reduces the risk of encountering problems during the sprint as you have already created a common understanding and plan to achieve the sprint goal.
When is the sprint planning meeting?
Sprint planning takes place on the first day of a new sprint. It always takes place after the sprint review and the sprint retrospective of the previous sprint. This allows you to incorporate the results of these meetings into your planning.
The Scrum Guide sets strict time limits. Depending on the duration of the sprints.
- Four-week sprint: 8 hours
- Two-week sprint: 4 hours
In a four-week sprint, many more user stories have to be discussed and analysed and the team has more time to estimate the individual stories.
Who takes part in Sprint Planning?
All members of the Scrum Team are present at the planning. The entire Scrum Team takes part in Sprint Planning. The Product Owner, the Scrum Master and the developers.
The primary tasks of the individual team members in sprint planning:
- Product Owner: Explains the individual stories she/he has written, prioritises the Product Backlog (with the development team) and then sets the Sprint Goal.
- Scrum Master: Possibly moderates the meeting, secures the time, coaches the team members to participate in the sprint planning and answers any questions about the agile principles. In addition, if I have the role of Scrum Master, I feel obliged (a fun duty 🙂 ) to question the teams if I perceive an estimate to be suboptimal. I want to protect the team from obstacles, such as bottlenecks, arising during the sprint, which put fellow developers in a tight spot. This causes stress, discomfort, the atmosphere becomes unpleasant and motivation goes down the drain. As a Scrum Master, it is my job to protect the development team so that my colleagues can work with verve, fun (having fun at work is extremely important!), motivation and creativity. As a result, the increments of the product are much better. As I always say ‘Happy teams, happy customers’
- Development team members: Calculate the team capacity for the upcoming sprint and define the scope by creating the sprint backlog. The development team can also help the product owner to refine the product backlog before the meeting starts. The developers are the single source of truth in Scrum because they are the true experts. It is therefore important that both the Product Owner and the Scrum Master (some colleagues in this role take the word Master too literally).
We recommend that a Scrum Master and not a Product Owner moderates the Sprint Planning Events – especially in the initial phase. A Scrum Master can ensure that all participants follow the agile principles and give the developers the freedom to decide on the scope of the sprint and the tasks they take on to fulfil the sprint goal.
A product owner also has enough to do before and during sprint planning, even if they are not leading the meeting. It is usually a welcome relief for them if someone else moderates the meeting.
Since Scrum does not recognise positions, but only roles, in which all participants work on an equal footing and, most importantly, autonomously, I see the Product Owner and Scrum Master as a real team that takes care of Product Backlog Management together. Although only the Product Owner is responsible for the Product Backlog, I see it as an advantage if the Scrum Master is on hand to advise and support the Product Owner.
Daily Scrum/Daily Stand-up or just Daily
According to the Scrum Guide, the daily Scrum is an opportunity for the developers in the team to review and adjust. They review their progress towards the sprint goal and adjust the sprint backlog if necessary. In the daily scrum, the product owner is an observer and listener and not necessarily an active participant.
While there are no hard and fast rules as to whether the Product Owner should participate in the Daily Scrum, there are several compelling reasons why they should:
The Product Owner can get an idea of the challenges the team is facing. The purpose of the meeting is not to give an update on progress, but rather to discuss progress and adjust the sprint backlog as needed. In this way, the product owner can
owner can get a feel for the challenges the team is facing. This can help the product owner prepare for future sprints.
Obstacles and blockers should be addressed during the daily scrum. The Product Owner may be able to remove or manage some of these roadblocks or blockers, paving the way for the development team. The development team may have questions about the stories in the sprint backlog or questions about prioritisation when a product defect is reported. This shortens the time a developer waits for an answer to an important question.
What is the role of the Product Owner during the Daily Scrum?
The role of the Product Owner in the Daily Scrum is to listen to the team, answer questions and, if necessary, support the team in removing obstacles and blockages.
Basically, it is the event of the development team. It is even said that if a team is mature (experienced and well-rehearsed), the Scrum Master does not need to be present because the team can carry out the Daily Scrum autonomously.
I was always there because I enjoyed being with my team. I was ill once and had to go to the doctor, so a colleague from the team suggested to my colleagues that the Daily could be postponed so that I could be there ❤ 🙂
Backlog Refinement
At the beginning of sprint planning, the product backlog should contain the elements with the highest priority and relevance for the design of the sprint goal at the top.
These items should include acceptance criteria that can be used to check whether a particular item is actually completed. You can also create a definition of completion for the entire selection of tasks. This sets the standards that all tasks must fulfil.
As a general rule, all Product Backlog items should be DEEP (Detailed, Emergent, Estimated, and Prioritised): detailed, emergent, estimated and prioritised.
Some Scrum teams plan the refinement of the backlog as a separate meeting before Sprint Planning. In a Backlog Refinement meeting, teams can refine the items together by adding detailed steps to complete each task and estimate their size using story points, agile estimation techniques or a product like Sprint Poker. I will explain the topic of Print Poker in a separate post.
Sprint Review
What is the main purpose of a sprint review?
The sprint review is one of the most important ceremonies in Scrum, where the team comes together to review the completed work and determine if additional changes are needed.
The official Scrum Guide describes it as a working session and points out that the Scrum team should avoid limiting it to a presentation.
Perform a demo of the increment
This is generally considered the main purpose of a sprint review. Developers have the opportunity to show product owners and stakeholders what changes they have made.
Through hands-on experience with the product, the review team can then assess whether additional work is needed and take this into account when planning (and update the Product Backlog accordingly).
A demo isn’t the only way to showcase completed work. Other methods can also be used (e.g. mock-ups in Adobe XD®), as long as the goal of sprint planning remains the same: review, evaluate and adapt.
What Scrum teams Can learn beyond product presentations
Sprint review meetings should not be limited to a product presentation. Review and adjustment should be considered more broadly, addressing budgeting, skills, and schedules.
For example, a completed user story may have introduced an unexpected and undesirable level of complexity. The options that should be considered are starting over or continuing the work, but with additional resources planned for.
The Product Owner manages three important aspects of the Sprint Review and makes one important decision during the Sprint Review:
- Selection of the audience
- Organising the review of the product increment
- Updating the Product Backlog with feedback from the audience, and deciding whether to ‘release’ the Product Increment to customers/users.
The Product Owner determines the audience that is invited to participate in the Sprint Review. The audience should be as diverse as possible, with a focus primarily on paying customers and users, secondarily on investors or sponsors and, as far as logistics allow, on other business stakeholders.
The entire Scrum team must also be present to hear first-hand feedback on their work.
The review of the product increment itself should be as practical, tangible and interactive as possible. The product owner can prepare scripts that the participants can use as a guide and also allow the participants to ‘play’ freely with the product increment. In technical terms, the sprint review is like ‘user acceptance testing’.
All members of the Scrum team come together at the end of the Sprint Review to collect the feedback and allow the Product Owner to process it to the point where they can quickly update the Product Backlog.
This update may include adding new items, changing the order of items, removing future items or even adding items to remove work already done if the stakeholder feedback is negative!
If the Product Backlog never changes as a result of the Sprint Review, or if the product itself never needs to be adjusted as a result of the Sprint Review, then it is likely that the Product Owner will not reap the benefits of continuous improvement of the product.
The Product Owner has the sole authority to place the work of the Scrum team in the hands of the users at the end of a Sprint.
There should be no other people who have the authority to create additional releases without the approval of the product owner, nor should there be anyone who can prevent a release from being published if the product owner makes this decision. This is part of the Product Owner’s business decision-making authority.
If the Product Owner has this authority, they can achieve a high level of efficiency in meeting the requirements of the organisation or the market.
If the Product Owner does not have this authority, then it undermines their authority to order the Product Backlog (as this order becomes meaningless) and it undermines the ability of the wider organisation to hold the Product Owner accountable for the outcomes.
Other purposes of a sprint review
While the sprint review is not the primary purpose, it does provide an opportunity to regularly and frequently engage with stakeholders so that they can provide feedback and feel like valued participants in the project.
Other benefits include:
- Maximising responsiveness to customers
- team building
- Quality assurance
The Product Backlog
The product backlog is the basis for the success of the product owner.
What exactly is the product backlog?
The product backlog (PBL) is a sorted list of all relevant information that is necessary for the realisation of the product. The business and user needs are understood and documented in the form of a list of items.
These are usually in the format of user stories. The user story defines the need from the user’s perspective and then has some accompanying acceptance criteria to provide the team with the necessary details to understand what they need to fulfil that need. As more is known about the need, the user stories are updated accordingly.
Epic, User Story, Task, Sprint Backlog
Epics
An epic is a big story that cannot simply be achieved in a single sprint. It usually takes months for an epic to be completed. As a rule, it is a series of requirements that have not yet been broken down into user stories. Think of it as one big goal that still needs to be simplified and broken down into multiple tasks for your agile team to work on.
Epics are usually large in scope, not very detailed and need to be broken down into several smaller stories before they can be tackled. Epics are usually seen as a ‘top level’ or working hierarchy. Breaking them down into daily tasks, called ‘user stories’, helps an organisation achieve its overall business goals.
I also like to compare epics to categories. For example, an epic called ‘Register’ where all features (stories) related to this topic are assigned.
For example, the ‘Register’ epic could contain the following user stories:
- As a customer, I want to read the privacy policy before I sign up for my account so I can decide if I trust the company with my data.
- As a customer, I want to see a list of features and benefits on the sign-up page to remind me what I’m signing up for
- As a customer, I want to sign up for an account using my Facebook login so I don’t have to remember my username or password.
- As a customer, I want to sign up for an account with my email address so that I can control access to my data.
And in this example, the next epic step could be ‘Set up and customise my profile’.
6 best practices for using agile epics
There is no set template for epics. You can write it any way you want, as long as it helps you plan your work and communicate with your agile teams and stakeholders.
Whether you use a Scrum or Kanban process or a hybrid development process, epics will help you plan your work and report on it.
Here are some tips on how to make sure your agile epics are as useful as possible.
Start with epics and then with stories (top down)
Finding your epics can be done very well with a user story map. The top level ‘activity/product feature’ in the user story map becomes an epic and the levels below become the user stories and tasks.
If you are developing a whole new product, you can start with epics and work them out in more detail as development progresses to get an idea of the work that has been completed and is still outstanding.
Epics often correspond to features or major improvements (e.g. a redesign of a part of your product), but it’s entirely up to you how you want to structure your epics.
Give an Epic a good name
When naming your epics, keep in mind who will be using this information. For example, your agile development teams need to understand what they are building, and your stakeholders also need to understand your progress.
While a user story describes an end user need, it’s good practice for the epic to describe an outcome you want to achieve with it.
Consider these examples of epic names:
- Checkout flow V2
- Streamlining the checkout process
- Increase conversion rate in checkout
The first name doesn’t describe what it’s about at all, except that it’s a type of work at the checkout. The second name is better, as it describes that the checkout flow should be streamlined. The third name is even better as it contains a result that you want to achieve with this streamlining.
Und so könnten die User Stories aussehen die den dritten Epic zugeordnet wurden:
- Integration von Apple Pay (“Als Käufer möchte ich mit nur einer Berührung meines Telefons bezahlen, damit ich die Kaufabwicklung schnell abschließen kann”)
- Standardmäßige Verwendung der Rechnungsadresse als Lieferadresse (“Als Käufer möchte ich meine Adressdaten nur einmal eingeben, damit ich die Kaufabwicklung schnell abschließen kann”)
Dies gilt ebenso für User Stories. Ich habe es oft erlebt, dass User Stories sehr unklare Titel hatten, teilweise sogar Abkürzungen. Als externer Berater ist man in dem Moment hilflos und muss überall nachfragen. Das kostet Zeit und somit Geld.
Management-Tools, wie z. B. Jira von Atlassian, können Epics zum Filtern, Gruppieren und für Berichte verwendet werden. Daher ist es wichtig, einen Namen zu wählen, der für sich selbst spricht.
Geben Sie Ihre Epics die richtige Größe
Ein Epic wird in der Regel dann verwendet, wenn die Arbeit an einem Backlog-Element mehr als einen einzigen Sprint in Anspruch nimmt. Ein Epic kann in beliebig viele User Stories unterteilt werden, solange Sie den Überblick über die gesamte Liste behalten können.
Ein Epic sollte nicht zu groß und nicht zu klein sein. Als Faustregel gilt ein Zeitrahmen für die Implementierung von einigen Wochen bis zu einigen Monaten. Dies ist eine gute Größe für die Berichterstattung über den Prozentsatz der abgeschlossenen Arbeiten.
Zu große Epics bedeuten, dass der Fortschritt sehr langsam ist, der Prozentsatz der Fertigstellung in einem zweiwöchigen Sprint kaum ansteigt und die Berichte nicht aussagekräftig sind. Wenn die Implementierung eines Epos zu lange dauert, gibt es wahrscheinlich so viele Änderungen an den Anforderungen, dass die Berichterstattung über den Fortschritt fast bedeutungslos wird.
Wenn Sie ein Epic zu klein wählen, bedeutet dies, dass Sie mit einer großen Anzahl von Epics in Ihrem Backlog oder Ihrer Roadmap jonglieren müssen. Es kann schwierig werden, den Überblick zu behalten. Auch wenn Epics in sehr kurzer Zeit abgeschlossen werden (z. B. in einem einzigen Sprint), verursachen sie nur zusätzlichen Aufwand, ohne einen großen Nutzen zu bringen.
Verwenden Sie Epics zur Strukturierung Ihres Backlogs
Epics eignen sich hervorragend zur Strukturierung eines Product Backlogs, das normalerweise aus einer sehr langen Liste von User Stories besteht. Nicht jede Story muss in ein Epic aufgenommen werden, da kleine Teile der Arbeit einfach innerhalb eines Sprints abgeschlossen werden. Die Strukturierung größerer Arbeiten in Epics hat jedoch zwei Hauptvorteile:
Es bietet einen Überblick über die großen Elemente in Ihrem Backlog
Da sich die Größe eines Epos aus der Addition der Story Points aller zugehörigen User Stories zusammensetzt, bieten Epos auch einen Vergleich der relativen Größe von Initiativen zur Priorisierung.
Die Liste der Epics kann auch verwendet werden, um eine Übersicht über die Produkt Roadmap für das Senior Management zu erstellen.
Erfolgsmetriken einbeziehen
Bei der Definition eines Epics lohnt es sich, darüber nachzudenken, welche Erfolgsmetrik damit verbunden werden kann. Letztendlich dient jede Produktarbeit dazu, den Endbenutzern einen Mehrwert zu bieten.
Die Aufnahme einer Erfolgsmetrik in Ihrem Epic bedeutet, dass die Mitglieder des Entwicklungsteams und alle Beteiligten verstehen, was Sie mit dieser Arbeit erreichen wollen (Vision).
Einige Unternehmen verwenden OKRs, um vierteljährliche Ziele zu setzen. Der Verweis auf eine OKR-Metrik in einem Epos ist eine hervorragende Möglichkeit, ein Epos mit den Produktzielen zu verknüpfen.
Der Umfang eines Epics flexibel gestalten
Da ein Epic einen übergeordneten Arbeitsschritt beschreibt, der sich über mehrere Wochen oder Monate erstreckt, ist es wahrscheinlich, dass sich im Laufe der Arbeit neue Erkenntnisse ergeben oder neue technische Komplikationen (Impediments) entdeckt werden. Daher muss ein Epic vom Umfang her flexibel sein.
Der Umfang eines Epics wird durch den Umfang der zugehörigen User Stories definiert, die normalerweise in Story Points gemessen werden. Wenn neue Anforderungen auftauchen, können neue User Stories hinzugefügt werden, und der Umfang des Epics erhöht sich.
User Story
Here is a short paraphrase for the sake of completeness of this section. In another tutorial, this topic is covered in more detail.
A user story is a very detailed definition of the project requirements. It contains just enough information to give the Scrum team the right context of what the final product should look like and to calculate an estimate for completion. It is an agile approach that helps shift the focus from writing to talking about the requirements.
If the story is understood by all team members and all the work required to complete these stories has been divided into tasks and assigned, the story and its tasks are pushed into the sprint backlog.
When I take on the role of product owner, every single story is discussed with the team. Because my colleagues on the team are the experts and their assessment of the story I have written is absolutely important.
Task
Unter jedem Epic befindet sich ein detaillierterer Satz von User Stories. Und damit aus diesen Stories praktikable Komponenten werden, muss das Scrum-Team Aufgaben identifizieren und sortieren.
Scrum-Aufgaben (Tasks) sind detaillierte Arbeitsschritte, die zur Fertigstellung einer Story erforderlich sind.
Aufgaben können zwischen einigen Stunden und mehreren Stunden dauern und werden Teammitgliedern zugewiesen, die über die entsprechenden Fähigkeiten oder Kenntnisse verfügen, um sie zu erledigen.
Beachten Sie, dass eine Story erst dann als abgeschlossen gilt, wenn alle Aufgaben unter ihr erledigt sind (definition of Done DoD)
Die Aufgaben werden zur einfachen Nachverfolgung auf einem Scrum Board platziert. Im Allgemeinen besteht das Sprint Backlog aus den folgenden Kategorien:
Stories
- Zu erledigen – die Aufgaben, an denen noch gearbeitet werden muss.
- In Arbeit – Aufgaben, die das Scrum-Team gerade bearbeitet.
- Erledigt – Aufgaben, die abgeschlossen sind
Sprint Backlog
As described in the Scrum Guide, the Sprint Backlog consists of the Sprint Goal (why), the set of Product Backlog Items selected for the Sprint (what) and an actionable plan for delivering the Increment (how).
This approach is based on Simon Sinek’s Golden Circle (Why, How, What) methodology https://digitaleneuordnung.de/blog/why-how-what
Simon Sinek’s website https://simonsinek.com/
The Sprint Backlog is an overview by and for the developers. It is a clearly visible real-time picture of the work that the developers plan to do during the Sprint to achieve the Sprint Goal. The Sprint Backlog is updated during the Sprint when new insights are gained or all tasks are completed. It should be detailed enough that the developers can check their progress in the Daily Scrum.
Epic Template
There is no set format for an epic, but a few things are useful, as described above.
- Choose a good name that speaks for itself.
- In the description, give a high-level overview of what the epic encompasses. Reference business goals to clarify how the project relates to the company’s professionals.
- The success metric describes specifically what will be measured after this epic is completed. Big User Stories means a user story at the level of the entire epic. This is very useful for documenting how this epic provides value to your users.
Epics together with OKR (Objectives & Key Results)
A common problem is that most teams don’t see the big picture. No matter how hard the management tried to communicate the company’s vision and strategy, there was still a big gap between the vision and strategy and the work the teams were doing. Almost no one knew if and how they contributed to the company’s success.
How can OKRs close this gap?
Unfortunately, most Scrum teams become “feature factories” that deliver a feature and start developing the next feature. They don’t stop to reflect and analyze whether the feature really solved a problem or made the lives of their customers or users easier. The question of the result of their work remains unanswered.
If the team and organization want to break out of the feature factory and instead remain aligned but still autonomous, result-oriented OKRs can help. A product goal in the form of an OKR derived from the company’s goals can help the team focus on what’s most important. After delivery, the team can analyze the result by observing progress in the key results (as described in the Scrum Guide “Progress in the key results (as described in the Scrum Guide Progress towards goals”). The key, of course, is to write measurable results
Depending on the information collected along the way, the team can redefine its approach and the activities it performs in the sprints.
How do OKR and Scrum work together?
I am personally very happy about the new addition of “Product Goal” and the “why” in the Scrum Guide 2020. WHAT is to be done is already in the PBL (Product BackLog), the WHY helps the DevTeam to understand the value that is to be realized at the end of the sprint. How the new feature helps the customer/end user with their problems.
The Product Goal helps the teams to make their rather abstract product vision more tangible. If a team wants to make the product goal even more tangible and measurable, then the use of OKR is recommended.
OKR definition: Every 1-4 months (depending on the pace of the organization), the team and other stakeholders can write an OKR sentence that manifests the direction and focus for the next period.
In case more than one team is working on the same (sub)product, it is not necessary to write one OKR set per team. Each team can contribute by focusing on different key results. However, it depends a lot on how the teams are organized and how the OKR set is written.
Product Backlog: Based on the OKR set, the team can identify which experiments, activities, features, initiatives, etc. would help them get closer to their goal. This will also make decision making much easier.
Sprint Review > OKR Check-in: After each sprint, the team can observe the result, the development of the key results. If there are none, what could be the reason? Should the team rethink its approach for the next sprint? Maybe experiment in other areas? OKR Check-In meetings are an opportunity for these kinds of conversations. They are not status update meetings.
OKR review
At the end of the OKR cycle, i.e. after many sprints, it is time to reflect on what happened. Everyone involved can evaluate their progress on the key results.
- Evaluate progress on the key results.
- What results have been achieved?
- Did we reach the goal? If not, why not?
- Did we even choose the right key results? Have circumstances changed? Is the goal still relevant today? What do we learn from it?
- What should we do differently in the next iteration?
With all these insights, the team can now start the next OKR cycle by writing a new or adapted set of OKRs.
