Posts Tagged Agile
Ever since I was a child I have had this instinctive urge for expansion and growth.
To me, the function and duty of a quality human being
is the sincere and honest development of one’s potential.
Working as active Scrum Practitioner for almost 9+ years I have come up with my understanding of what is Scrum Master’s role, service to the team and key responsibilities. Earlier I have written about what Scrum Master should master, here I would like to concentrate on 8 Key Aspects of Scrum Master work. Focus areas so to say. Here those are….
- Facilitates Sprint Planning Meeting
- Facilitates Sprint Review Meeting
- Facilitates Backlog Refinement (aka Grooming) Meeting
- Facilitates Sprint Retrospective Meeting
- Facilitates Daily Scrum
- Facilitates Release / Roadmap Planning Sessions
- Facilitates whatever/whenever else Team and/or stakeholders communication is required to be facilitated (not about any collaboration)
Purpose: to improve shared task clarity, planning, bring in more transparency over status quo for team to see where do they stand (and plan to go, and what have they achieved and how they want to improve) and their work results, help team to be able to enhance communication and perform their daily work
- Cultivates “us” vs. “me” culture and mindset
- Enables and fosters team to self-organize
- Helps team to make decisions
- Supports team through stages of its development
- Coaches individual team members on communication, collaboration and teamwork when necessary
- Increases “bandwidth” of communication among team members
- Observes team and talks to every single team member
- When required does one-on-ones to help through raising conflicts
- Navigates conflicts (involves management when necessary)
Purpose: to build up better team => better understanding each other => improved collaboration among team members => improved team performance
- Guards team agreements, decisions and process (e.g. retrospective decisions, agreed “howtos”, DoD, DoR, review process, etc)
- Make team stick to its agreements, drives teamwork and respect towards owning decisions, leading to performance improvements
- Keeps balance between fulfilling business (Product Owner) needs and maintaining team sustainable pace, so that business needs are addressed by PO requests while team development and pace is not forgotten.
- Makes sure environment is as Team empowering as possible. Empowerment raises team feeling of ownership that rises up dedication and servers to better results
- Helps the team and Product Owner to maintain their artifacts (product backlog, sprint backlog, task and action boards, sprint/release burndown charts, tickets comments, story maps, etc.)
Purpose: create and maintain environment where high demand is possible. Here is why that is important
Impediment “Fisher” & Resolver
- Creates environment for effective impediment “fishing” and removal. Cultivates transparency and information radiation as pre-requisite for impediment clarity and removal
- Enables team to respond to impediments
- Raises awareness of team’s impediments
- Coaches team in resolving impediments (the one’s that could be solved by team)
- Helps team to discover new impediments (wastes). Constantly questions the status-quo
- Helps to resolve impediments / take ownership of those cannot be solved within / by team
- Improves efficiency of the team by helping with eliminating impediments
- Escalates and follows up on impediments to where they belong
“High Focus” Promoter
- Shields team from external interferences (extra tasks, todos not agreed with Product Owner, etc)
- Enables team to concentrate on most important todos, achieving “state of flow” and high concentration.
- Helps to avoid wastes caused by context-switching and to avoid team member burn-outs
- Gardens team’s sustainable pace, so that combined with “empowered” environment of high demand is possible
- Increases feeling of “urgency” and highlights how much is left to achieve (e.g. tickets, story tasks, story points, etc.), e.g. with the help of burndown charts, tickets left, etc.
- Helps team to focus on regularly achieving small thing to create feeling of fulfillment and good progress
Motivator and Coach
- Promotes positive thinking, open, honest and respectful feedback culture
- Motivates team to improve team productivity regularly
- Helps to raise team morale, to increase dedication and to improve team deliverables
- Helps to create feeling of achievement
- Creates environment of excellence and continuous improvement (and mindset of seeking for improvements)
- Creates mindset of “quality first”, intolerance to poor quality and continuous improvement
- Regularly takes care of team’s “happiness” (and involves management when necessary)
- Coaches and teaches required mindset, frameworks and engineering practices (Lean thinking, Scrum, Kanban, XP, pair programming, continuous integration, test automation, etc.)
- Teaches and integrates new team members into working process and agreements (and into the team)
- Serves as agent for change and positive challenger of the team
- Reflects integrity and leads by example (e.g. being on time, continuously self-improving, sticking to agreements, etc.…)
- Reflects Lean thinking and Agile principles to the team
- Reflects on reality and promotes transparency on status-quo to question
- Makes things measurable where applicable and possible to illustrate team progress: brings transparency about what is done, how much is achieved, so that weaknesses are easier to identify and potential improvements are easier to see
- Helps team to radiate information (e.g. burndowa, burnup charts, impediment boards, hapiness matrix, knowledge matrix, peerwork matris, etc.)
- Introduces required measurements for team to see regularly its work results (e.g. tickets achieved, stories done, story points achieved, bugs popped up/fixed, retrospective decisions implemented, ..)
- Uses collected data to think and question team and act if required
Agileist: outside of Scrum Team
- Shares Agile/Lean mindset within organization
- Shares best practices and tools, so that other Scrum Masters can benefit / see different perspective of managing things and company can benefit from enriched toolbox of methods and practices
- Collaborates and helps other Stakeholders to learn how their requests could be fulfilled with the team doing Scrum (or Kanban), so that other Stakeholders could get their requests address while team’ pace is also protected
- Helps to improve organization by creating learning organization
- Helps to address organization’s impediments
Last and not least there are many other things that do not belong to this structure. Those are dependent on situation and circumstances. And those are still handled by great Scrum Masters 🙂
Before everything else, getting ready is the secret of success.
Many of us doing Agile do not understand that it is primarily business mindset, rather than just another methodology to deliver software. Balance and sustainability of constructive conflict (key driver of any prosperous business) is the secret sauce to implement Agile successfully.
Let me explain it from practical business perspective. I will drift away from IT and software now…
Imagine you’re running business delivering…. car repair services to your customers.
It is your interest to deliver services fast and having quality in, so that you retain your customers and attract more (as it’s known that satisfied customer may bring 1 or 2 others, while dissatisfied one may stop other 8 coming to you). On one hand the more services you deliver, the more money you get, so you will push for more. But if you start pushing harder than your team is capable of, your service quality will start to suffer and this will obviously cause problems with your customers.
So you will try to get as much as possible given your conditions, while keeping quality in.
Now let us look at it from your customers perspective…
They want to have their car repaired cheap, fast with quality in. When you say your’re busy this week and cannot take their car, they will consider someone else’s services, rather then agree waiting that log (reality of market competition);
So, there is conflict of interests and mismatch between demand and offer.
It drives 2 things:
- Your business development (we need to improve our service to deliver faster/more/cheaper);
- Your customer’s expectations (maybe these repairs are not doable that fast/that much/that cheap);
Two consequences out of that:
- When there is no demand, why should you care to do more/faster/cheaper?
- When there is no chance to change your customers expectations either you’re doing poor job or your customer won’t likely get any better services with reasonable price anywhere else (task for your client managers to drive customer’s expectations).
So mismatch of those two creates conflict of interests that drives change.
The art is to understand to what extent you’re capable to improve things at your business given your current circumstances, while managing your customers expectations in the way to have control over gap between your offer and your customer’s demand.
Controlling this implies another important thing: ability to recognize challenge that you will fail taking (you should constructively resist) and challenge you’re able to overcome (and should take) to improve and continue managing “the gap”.
If you do not understand this you will end up bad. Either you will not be able to deliver quality in to your customers or you will be “beaten” by your competitors. In both cases you will end up being out of business :(.
Now let’s come back from cars to software and Agile
Customer is Product Owner (PO), while your business is your development team. The more you think business-wise and consider your team a business the better your team will be satisfying your PO.
So it is as easy as managing just 2 things:
- Your PO’s expectations;
- You development (quality and predictability);
Agile is just business common-sense mindset, nothing else! So to implement it right start from considering that you run a business in a highly competitive market with goal to satisfy your customer.
And mind that there is difference between pleasing and satisfying your customer, so argue, stand for your point, do not let compromise quality, do never over-commit, protect your ability to deliver, manage expectations, and … satisfy. If you do not follow these simple business rules and will focus on just pleasing your customer (or PO) just as in business you will end up not being able to manage what you’re responsible for – QUALITY.
Good Luck 🙂
Many Agile coaches have their own list of top failure modes. My favorite one is Mike Cohn’s: “How To Fail With Agile: Twenty Tips to Help You Avoid Success“.
But I also want to publish my winning list of things that impact teams and undermine their trust in business and Agile (combined from experience gained observing different teams at different times, so no particular team is meant here 🙂 ).
So tips are written from the Product Owner perspective:
1. Argue in front of team at Sprint Planning. Let them see you were not capable to decide what you want to build them. Moreover, involve them into arguing. This will demonstrate how your (PO) team misses integrity;
2. Demonstrate that being on time does not matter: interrupt meetings with calls, side talks and questions. Leave the room occasionally and be late regularly. Doing this will make it almost impossible to demand on-time delivery from the team;
3. Continuously fail to deliver INVEST stories and integrity in sprint goal/product backlog. Let stories w/o details thought through, so that team feels you had not invest enough time to prepare them. This will also make it easier for team to fail delivering outcome of that stories to you, will make things more ambiguous, so that no one will understand where is failure or what was wrong and will never learn from it, so that improvement will not be feasible;
4. Ignore team signals on complex stories (the ones that are above ~13 story-points, the ones that are risky, big, and usually need to be analyzed and split into smaller chunks in advance). Just let big stories that have big doubts, leading to easier underestimations, over-commitments, sprint failures, causing less team confidence, further under-commitments and wastes of all kinds;
5. Present deadlines ignoring reality “I do not care how you do it, it MUST be done”. With this “masculine” management style you can always push things forward as Agile teams just delivery chain, so they must obey and no matter what they think and capable of;
6. Never share the Product Vision and mid-long term roadmap with the team (just keep it secret);
7. Ignore technical debt (just concentrate on #5);
8. Bombard team with in-sprint questions and “Can you do it now please?” tasks. Explain them that SCRUM is good but now we need to be more “FLEXIBLE”. Moreover, assign tasks to team members without talking to entire team. Demonstrate that you were not been able to plan things for an iteration, this will ruin team trust that they are working on most valuable things and completely undermine their ability to deliver;
9. Never groom your backlog just leave it to the sprint planning meeting when it is already too late. This will lead to long and stressful discussions as you will have to do it mid-planning,will drain team energy, lead further to fatigue, wrong estimations, poor planning and sprint failure;
10. Always try to find something that team did wrong to pin point and focus on blaming. This is proper way to avoid Kaizen and let team protect themself by “storytelling”;
Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.
Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.
I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.
Let us discover some sick stand-up/self-organization symptoms first…
1. Refraining from exposing problems (ignorance of reality):
- Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
- Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
- It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
- Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
2. Intolerance to critical feedback:
- Team member pushes back heavily when someone tries to rise a problem related to his/her task;
- Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
- Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…
Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?
If yes then…
Try out following cures ….
- Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
- Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
- Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
- Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
- Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
- Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
- If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
- Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
- Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);
To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.
“People like talking about people. Makes us feel superior. Makes us feel in control.
And sometimes, for some people, knowing some things makes them care.” [HouseMD #113]
As described in earlier post in “TEAM: 7 indispensable ingredients for Together Everyone Accomplishes More” one of the key elements of a strong team is Brand.
An idea to apply known brand-building practice to team management seemed to me interesting and made me write this blog post.
So I would like to cover a useful tool that can be applied to build up your team brand…
Team Brand is essential team motivator that cannot be given to the team (by company, management, money, etc.), it needs to be build inside, owned and maintained by the team. Actually this is type of “achievement” and “idea”-motivator for a Team (here cross-functional, self-organizing teams are meant, although practice is applicable for any team of small size).
In other words, Team Brand serves as an alignment on its core values/ways to achieve, inspires team by having strong and challenging core set, while distinguishes team among others.
Team brand may be built as any corporate brand starting from key cause or a purpose, moving from core through the benefits (qualities, values) to attributes (tools, norms) supporting and transmitting them.
Well, but an agile self-organizing team needs a hint to start thinking of themselves as a “company”, having a “brand”. A hint that envisions this mind shift would sound like: think of your TEAM as of an entrepreneurship and your collaboration as of an inspiring challenge! Imagine you’re running business with your peers (which is not that far away from reality, considering self-organized development team doing SCRUM).
- WHY are we here, what we want to achieve together, what is our core, our strongest believe and our purpose? Why do we exist as a TEAM? Which core value we all share?
- HOW we can make this happen? What principles (benefits, qualities) support this?
- WHAT we exactly will do (and will NOT tolerate) to support each of the key principles we’ve agreed upon that contribute to our purpose?
A tool I recommend to use at this step to create and maintain team DNA is known “Team Radar” retrospective facilitation activity (see “Agile Retrospectives: Making Good Teams Great” by Esther Derby and Diana Larsen for detailed explanation).
It simply suits best this exercise. Here it is used to gather data on team itself and perform self-assessment in the future.
An outcome applying this practice to an Agile self-organizing team may look like this:
As soon as agreed Team DNA is documented, printed out and placed in visible area (ideally at the team scrum board and/or also very usefull in retrospective room). This will serve as a point to refer/remind when choosing for right decision/action and will keep team motivated to comply everything they think, decide and do with their core.
But this “artifact” shall not be “curved in stone”. It’s living, since team is also living. So on and on reviewing it, team curves itself, making their brand stronger and more unique, by finding out deeper levels of their own common values, purposes, beliefs and means, achieving them.
The more team does so, the more it finds it’s own distinctive way doing things and becomes more distinguished (“branded”) and valued by managers, stakeholders, POs, etc…
Good teams that value the way they perform and look, care about this and move further finding out more challenging cores, supporting principles and norms.
Besides that it’s a funny collaborative action that contributes to team building.
Brand up your Team, guys 🙂
- “How to Build and Manage Your Brand (in sickness and in health)” ebook
- “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))” by Lyssa Adkins
- “Branding Governance: A Participatory Approach to the Brand Building Process” by Nicholas Ind and Rune Bjerke.
I had my CSM training in Stuttgart, Germany this spring where I first met Jeff Sutherland.
Well it wasn’t just that… training. Listening how he describes Scrum creation and rationales behind each artifact/ceremony/role was an experience! Having him answering simple and tough questions (and not only about Scrum) had helped a lot!
I felt as I occasionally discovered new dimension of Agile where everything I knew until then immediately got the depth, with lots of insights to generate own ideas.
It was two remarkable days with Agile evangelist, Scrum co-inventor, and great Scrum practitioner.
Thank you, Jeff!
From the fist look Agile may be obviously beneficial, however getting customer there is not that trivial as it may seem to.
Let’s take an example I’ve came across recent times.
An online service wanted to have new web application developed (for certain reasons I cannot specify it’s name). It turned to a team, giving high level detailed specifications and asked for estimates (both budget and time-wise).
Or another one: “… we’ve got budget fixed and cannot afford us more. Can we get our application for it then? How we can have guarantee that we’ll cover key functionality we need, ha?”
Or… “Just tell me when it’ll be ready and how much it’ll cost”.
Well, the scope is usual trap here. Customers may have a rough idea about scope (in some cases they could have even detailed specs defined). In both cases it ends up having either nothing specified or too much specified making them hardly answering realistic scope question and leaving team being not able to forecast or making dangerous guesses.
Familiar cases, aren’t they?
To address situations like these I combined my sales experience with known Agile benefits and came up with simple 10 step practice.
Here I go…
To get the point how to sell best it’s needed to get closer to the reasons why your customer demanding to have fixed contract: most likely he may want to be sure he will NOT spent more budget or time then he has in mind to to get the imaginary scope. There may be plenty of other reasons as well…
Only getting answers will help you to prepare your deal properly.
Here are simple steps I found working dealing with fixed contracts:
1. Prepare (before you start): think of the reasons and ways to make sure you understand limitations and rationales for fixed contract for your particular customer. Stop here and think!
If you’re not sure you understand those, do not sell as you’re not prepared yet and you may offer wrong benefits, operate using wrong terminology, stress not important aspects, etc… This is key point. Prepare your deal before moving forward (I promise another post to explain how to get clear and move forward).
2. Set the stage: explain Agile (SCRUM) rules without selling them at this point (just simply telling how it works and what it looks like process-wise from customer perspective). It is important that at this point you still do not “sell”, just take time to explain Agile. Get feedback cautiously and to see if customer gets it. Continue explanation until he gets a full picture and feels confident with “mechanics” described. It is also important not to overdo it: it should be easily understood, sound light-weight and non-technical at all;
3. Step forward: offer first planning session for free (this works). This will help customer to both get more involved and feel more secure moving forward. Explain that by this you’ll mutually try collaboration with each other “softly”.
4. Involve (offer help): some clients want to (or like to) develop specifications on their own, some want to have contractor or 3rd party side PO doing this. In both cases customer needs some help getting started with story writing as it requires knowledge and practice.
5. Agree on conditions of satisfaction of each feature (aka Definition of DONE), since it will have an impact on estimations. Do not be technical here if you deal with business people (or be if you asked to explain it to CTO or a tech guy). Again be cautious here: some tech guys have their own opinion on what is important (is not) that is hard to change (and also wrong). It may be that you end-up knocking into the closed door if you start offering without asking what is considered as important first place.
6. Follow up after first planning session by helping to re-calculate to contract details:
- story points to time, knowing team baseline (assuming established team with agreed baseline of estimation);
- sprints required (knowing team average velocity) to the budget required;
It may be required to estimate entire scope. There are known techniques to do so. Goal here not to be exact (since you’ll never be) but to create feeling how much features customer gets approximately for a single sprint budget and/or how many sprints it will take to cover entire project. Usually this impresses (because Agile teams are way more faster than others). Then move forward and SELL!
7. Sell: stress that with Agile business is riskfree, since your customer will:
- avoid big-bang integration and “surprise parties” (by releasing as early as possible);
- observe potentially shippable software every sprint, having all required qualities-in (DoD);
- be able to adjust what features are most beneficial per sprint and ensure that team working on top important ones;
- be able to get end-user experience early to steer the product in the optimal way further;
If you’ve done everything correctly already here you should have READY customer. But he’s not fully there yet (or still has some doubts). Stop. Ask for doubts directly. Take your time to explain. Continue until all doubts are addressed. But you need a final “stroke” make customer feel more confident.
8. Pause (optional): there are two options how to continue at this point.
- Let customer “sleep over” with everything above (I usually do that), but it depends on what extent is your customer “boiled” here. Short waiting is good, because it lets sale process within customer’s organization to take place (aka “inside sale” stage). Involved managers discuss here and come to the point to sign/not to sign contract with you.
But here’s the trick I apply: you should try to know by when decision shall be made and act a bit up-front in time (#9). Because if decision is made it may be too late (in many organizations it usually is).
- Continue if you sure customer is ready for another “strike”;
- option to terminate contract at any time after sprint review session (with some benefits for you, of course).
- option to swap features and do changes in scope at any planning session.
10. Close your deal.
Roadmap planning is indispensable part of Agile project management that represents second level of 5 levels of agile planning that any team should somehow cover. As a best practice suggests it needs to be done by product owner every ~2-6 months, depending on the intensity of development.
This exercise makes sure that entire team understands direction, goals and vision of the product team, brings many benefits and speeds things up by creating shared clarity about future and maintains high focus on the “vector” PO gives.
Recently I’ve facilitated Roadmap planning session applying two techniques: planning poker and story map. For those who want to get details of both techniques I would recommend nice extract from Mike Cohn’s “Agile Estimating and Planning”: http://planningpoker.com/detail.html and this nice article at Jeff Pathon’s blog: http://www.agileproductdesign.com/blog/the_new_backlog.html.
It was both interesting and challenging, especially since we’ve never try this before. It was great success since resulted in having clear, estimated and planed Roadmap for product fist steps.
- To share product roadmap and vision;
- To make challenges and risks visible and clear and address them early;
- To make approximate measurement the minimum required scope of the release of the product;
- To predict possible release date range / manage product scope in the way to hit deadline;
- PO prepared items (user stories and/or themes) written on index cards (one per card);
- Items were grouped according to the story map (by corresponding key product functional areas);
- Key area titles were stick to the glass wall at our big conference room;
- Horizontal line was drawn to separate the first release content over the wall;
- Scrum team in one room for 2 days;
- PO presented key functional areas of the product being built, briefly describing what each area covers;
- PO started presenting item after item, sticking on the corresponding map column of the wall, given priority he had in mind.
- Team estimated item presented with planning poker.
- When estimations were too different we’ve allowed 1 or 2 rounds of re-evaluations. Well, we did not played exact poker, since we were interested in the approximate estimations, so we took averaged estimations (i.e. majority raised 5USP, some guys 8USP, 6 or 7 is taken as an average, more feeling-based);
- As soon as a column was complete discussion on required minimum scope of the release content started and PO moves some items below/above “scope line” (also considering estimations and best guessing for ROI).
- Moving on and on to the next product column and item after item of a story map;
As result of 2 days workshop we’ve manage to:
- Gain shared clarity about what needs to be done to get product LIVE;
- Identify biggest project risks and “hairy topics” with poker estimations (those had usually high estimates, more than 20 USP, clearly);
- Agree on next steps (to start with risky but must-to-have items first);
- Noticed dependencies among items and moved them up/down in the way to decrease them;
- Estimate roadmap and predict delivery dates range (we’ve ended up having kind of 500 USP);
- On the level of details where items represent Themes rather than a requirements or stories according to the cone of uncertainty estimations vary from 0.8 to 1.25x factor. On the requirement/story level they also vary from 0.85 to 1.15x. Considering this I took an average ratio, given the fact that some items were story sized, others were bigger (nice article that illustrates correlation between estimation accuracy and uncertainty from Agile101: http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/).
- This number together with average team/historical velocity gave an idea of the range required to get product out within agreed scope;
- Roadmap planning is a valuable and must to have regularly exercise;
- It is both interesting and motivating for team members;
- PO gains a lot of important insides about product that allows to manage release scope and prioritization to minimize risks and get to live ASAP;
- Teams are enabled to plan more than just in time architecture since bigger picture of the product becomes visible;
- It shall be done outside of a sprint to guarantee 100% clear mind and focus;
P.S.: * many thanks to my CPO, would be impossible without his preparation and buy-in.