Splash | Applied Frameworks

Starting and Ending Sprints Successfully with Remote Teams

Written by Jason Tanner | May 23, 2023 4:00:00 AM
In this fourth episode of the Agile Experts webinar series, you’ll learn how to start and end Sprints successfully with remote teams by facilitating engaging Sprint Planning and Retrospective sessions.

Miro and Applied Frameworks hosts will be joined by Mitch Mikusek (Sr. Engineering Manager at Salesforce) and Tanner Wortham (Executive Coach & Agile Consultant).

Sprint Planning and Retrospective are the pivotal moments where we set the stage for success and continuous improvement. However, these conversations can often become repetitive and unengaging, especially for distributed teams. But fear not! In this webinar, we introduce you to two powerful techniques that will transform your team’s planning and retrospective sessions into dynamic and meaningful discussions.

Allow us to introduce you to two techniques we guarantee to motivate more engaging, lively conversations at these critical moments with your team. After our time together, you’ll walk away with more tools in your facilitation toolbox

  • Learn how to create the right “containers” for meaningful conversations
  • Turn a large messy backlog into a sprint-ready plan in just a couple of hours with Multi-Pass Planning
  • Quickly estimate the size of an entire backlog of stories with Fast Fibonacci
  • Leverage concepts of divergence and convergence as facilitators to engage your team
  • Gain pro tips and watchful gotchas for preparing your next planning and retrospective sessions

Not able to make the Live session?  View the Recording | Check out the Presentation | Get the Miro Template

Questions & Answers

Question: How can we find Miro’s product roadmap to know what future features are being considered and their potential release dates?
Answer: We always have a lot of things cooking at Miro – I’d recommend joining our us during our What’s New webinar to keep track of what’s new and which features have been launched. Read more at www.miro.com/whats-new

Question: Can you go further into depth about Indicator data. (examples)
Answer: I don’t quite recall the context in which I mentioned it so I’ll speak in general – all the data we produce while developing solutions might be percieved as “Health Indicator Data” – some likely more valuable than other – by Health Indicator Data, I mean we can inspect that data and retrospect / hypothesize on what might be causing certain trends in that data. From there we can choose to experiement with practices that motivate change in the data in a positive way.

If I was speaking about sizing / importance / urgency / priority as indicator data, its just data but a shortcut we use to understand a certain measure of an item (at a glance) and represent some deeper, more complex thought went into evaluating its size. Even if performed quickly, its a summary of the individuals thoughts and perspective in the moment they decided to place it in say an importance level of 4.

Question: Have you tried Open Space planning (FAST Agile)?
Answer: I personally haven’t but I’m adding it on my list now! Thank you!

Question: Doesn’t Sprint 0 does this cleaning job for the Backlog? What would be the difference between these two?
Answer: I view sprint 0 as a time to make these investments – where you could choose to use this practice, Multi-Pass Planning, to give you the first pass at your backlog, and then leverage the focus it provides for the remainder of your sprint investments.  Additionally, Multi-Pass Planning this is intended to be completed within around 3-4 hours, so can be additionally valuable if you are short on time (or want to manage these types of investments).

Question:  Can you share the link to this Miro board?
Answer: We’ll be sharing all webinar resources, including the recording, via email – keep an eye on your inbox

Question: How can I start sizing my backlog with people who is your first time with this activity?
Answer:  I think the answer to think depends on a lot of factors – Are they familiar with Relative Sizing? Is anyone on the team familiar with Sizing? Is it just the “Fast Fibonacci” technique that needs more guidance? If they aren’t familiar with sizing, you’ll likely benefit from reviewing the goal, intent, and any established guidelines the team uses.  If the exercise is new to the entire team, the relative sizing exercise can still be useful, but you’ll want to leverage retrospectives to learn and adjust the scale you used in the exercise (or leverage the new information in an upcoming team backlog refinement session)
I’ve learned of “affinity estimating” while responding to these questions, and it seems to be very similar to the technique I described, so you might find some detailed examples on facilitating the exercise by using that name.

Question:  We are importing from which tool? Kanban?
Answer:  Mitch is demonstrating an import from JIRA.

Question: When working with cross-disciplinary teams, how do you handle estimation practices? Sometimes it feels like they are able to weigh in on the effort/complexity of other discipline’s tasks, but not always and it does not always feel useful. Especially other disciplines weighing in on engineering – do you typically keep estimation to only discipline level vs team? Or do you still do team-level but have some other tactic?
Answer: A team-level estimate is most useful for a Scrum Team to align on the effort required to achieve the Sprint Goal as a team

Question: Is sizing an effort matrix?
Answer: The sizing exercise itself isn’t intended to be an effort matrix, as we’re trying to leverage focused perspectives to review the backlog at each step, but certainly, the Priority vs Cost conversation you could have in the final step might lead to conversations very similar to an effort matrix

Question: How to estimate with different teams, like UX, QA, and development?
Answer: Ideally, the cross-functional team of UX, QA, and development estimates together to identify the effort required for the whole team.

Question: With relative sizing, are you using stories from previous sprints as standards to size against? Small, medium, and large of things that you’ve done before?
Answer: The choice of Reference stories I’d leave to the team – If we have established reference stories from prior sprints, they are wonderful choices. If we don’t but feel we could quickly agree on a prior sprint item and its size, then that could certainly work! Reference stories aren’t necessary, though; they just aid in bringing consistency to our sizes – Without established reference stories, we measure with a different ruler each time.

Question: What’s the max cards you would do at a time?
Answer:
 I’ve seen the exercise work successfully with 100 – 150 items – but I’d also argue once you get over 50, you likely reached an incomprehensible number of items – this exercise should help provide focus if you aren’t able to identify where to trim down to 50 on your own.

Question: How can you bring them from Miro?
Answer: In this example, the Jira connect imports them to Miro, and edits to the cards on Miro sync back to Jira – Jira has a size field, but you might need to add custom fields if you want to enter the Importance/Urgency/Priority data on the ticket.

Question:  I have 2 questions: 1) My experience is that sizing based mostly on complexity with minimal consideration effort is the best practice. The reason for this is: effort changes based upon who is doing the work and when you are sizing you don’t know which individual will do the work. I feel like multi-pass has a fairly strong focus on effort am I understanding you correctly? 2) This sounds very similar to affinity estimating which a difference being affinity uses a baseline for comparison. Again, am I understanding you correctly?
Answer: 
1) If a focus on complexity seems to work for your team I wouldn’t suggest changing it but I find having it as part of the vocabulary for my team’s sizing is useful.Certainly we the skill difference exists that simplifies effort and complexity but in many cases we can agree on “Relative” complexity/effort – and if a member of the team is aware of information that reduces (or inflates) the complexity or effort of a story, its a great conversation for the team to teach and share knowledge.
2) I hadn’t heard that name before but it seems pretty similar, perhaps with more guidelines for facilitating – I included “Reference stories” in my example to act as baselines to anchor the relative sizes, although I wouldn’t say they are necessary (and I find many team’s dont have reference stories). Thanks for sharing, I love it!

Question: Is there a way to bulk edit card in Miro?
Answer: Hi Tom, you’re able to bulk convert Miro cards to Jira cards – to learn how, read more here: https://help.miro.com/hc/en-us/articles/360017572434″,05/24/2023

Question:  What happens when a team member moves the card to 2 and the other thinks its 3 or something else? Will they keep moving the card?
Answer: 
If team member seem to be having a “Tug of War” over a card, its a great indicator to the facilitator to pull it aside, allow the easy answers to come out, and then we can give a little extra attention to the card that was moving around. Usually we can establish a set of common assumptions to help drive alignment.

Question: Can ADO issues be imported similarly to what you are showing with Jira?
Answer: Yes, they can! Take a look at https://help.miro.com/hc/en-us/articles/360033799934 to learn more

Question: How can we estimate the sprint without estimation?
Answer: I suggest using a team “velocity” as just another “indicator” piece of data but not one that should drive decisions on its own. So when sprint planning, velocity might highlight we’ve taken more than normal, or less – and this is something we can discuss as a team – but if you dont have it, its totally fine to collaboratively establish a sprint goal and retrospect on our ability to meet it later – but I trust the team’s more thoughtful perspective on if our sprint goals are achievable as they’ll be able to consider our strategy for delivering the items and the unique constraints they’ll pose to our team than a single velocity number.

Question: Is there a quick way to transfer tasks from Jira to Miro?
Answer: Hi Natalia, to learn more about how to use Jira Cards in Miro, take a look here: https://help.miro.com/hc/en-us/articles/360017572434

Question: How do you import the tickets from Jira to Miro
Answer: To learn more about Miro’s integration with Jira, have a look at https://help.miro.com/hc/en-us/articles/360017572434

Question: Are you manually typing in the data into each card?
Answer: Yes, it is manually captured – either on the card, in the summary, within a textbox, etc – some tooling here could make it much nicer for sure!

Question: The priority phase is manual? or is it an automated process?
Answer: Its Manual – if you get the whole team’s help it tends to go quite quickly though

Question: It would be cool to see you do this live instead of the slides
Answer: Great suggestion! We’ll be looking into incorporating more live workflows in these webinars – thanks for the idea!

Question: Why is this specifically for remote teams?
Answer: The technique will work for in-person teams. Mitch was demonstrating how to do it with Miro as a tool for remote teams to leverage the same technique.

Question: How can you help teams understand the difference between important vs. urgent?
Answer: Yes. It’s important that we are prepared for the holiday shopping season in December. In January, it’s not urgent that we are prepared for the holiday season at the end of the year.

Question: Would you also say that prioritizing related things together is beneficial in the review stage to gain efficiency during implementation?
Answer: It’s certainly a consideration as it might make the ROI equation worthwhile – but we also don’t want to fall into the trap of prioritizing things because they feel more convenient but don’t represent high enough value. Even the minor additional effort saved might be better invested in other areas.

Question: It is correct to say that if one of these issues will not be added to the next Sprint Planning, we have to newly estimated all these parameters based on the new set of issues/card we are considering.
Answer: If you have a sense of what will be in the next sprint, this exercise might validate that assumption and they’ll bubble to the top – but this exercise is intended to extend far beyond a single sprint and provide a rough ranking for the entire backlog. As mentioned in another question, once we get beyond 50 items, we might consider dropping the remaining if possible as it’s unlikely we truely understand items beyond that point.

Question: Mitch can you explain the last slide in a little more detail?
Answer: The last slide shows two main images. To the left is the backlog, where the “blocks” are stories, and the size of the blocks reflect the story point sizes. An “Ideal” backlog likely has items in a gradient of sizes – near the top, roughtly 1-2 sprints worth of smaller items we refined and spiked – ready to bring into a sprint and relatively small in size (~1-5 pts). Just past those we start to see items 2-4 sprints out, larger in size (~5-13pts) but we likely have spikes in our upcoming sprint or refinements planned to review and break up the stories into smaller increments of value. Beyond that we might have much larger feature or epics, described a high level and in low detail – those large items might be 8-40pts. The image on the left is attempting to show that backlog (and potentially 6months to a year of timing).

The image on the right shows a forecast. Assuming we have some velocity data, we can use statistics to calculate a confidence interval that suggest upper and lower bounds – these are reflected in the green and red lines. Then based on the communication we want to have, we can communicate a range of dates for the delivery of a specific item, or a range of items that might be delivered by a specific date. Henrik Kniberg “Agile Product Ownership in a Nutshell” youtube video covers this nicely.

Question: I do agree typically 🙂 but I have definitely noticed a trend where the team finds it less valuable, especially when they feel like they can’t contribute (ex: an engineer weights something an 8 because they have a better understanding, an artist weights it at a 2 because they don’t fully understand the work). I think having a convo about that can be good/educational, but often it feels from the team that this doesn’t feel useful – have you had this issue before?
Answer: Yes, absolutely. In that scenario, I have seen teams “go with the 8” or “choose middle ground” and choose 5. The key – the conversation about the overall effort for the team.

Question: Fast Fibonacci, is that done by the whole team or just an individual? I ask because if it’s the whole team, wouldn’t that lead to a discussion on why each person gave the score they gave?
Answer: Live answered,05/24/2023 11:29:24

Question: Can you use the same template/structure for a CMVP product?
Answer:  Not familiar with the term CMVP, but if it involves a collection of backlog items that aren’t sized and/or ranked and would be beneficial to be both so we know where to start and can communicate around a forecast – then absolutely!

Question: How is priority calculated? Is it based on stakeholders’ needs or the complexity and severity of the product increment delivered by the team?
Answer: The labels in the exercise are admittedly a bit misleading. The real priority is influenced by cost – which encapsulates the complexity/effort/risks.
Beyond cost is the stakeholder needs and timing constraints – we called these “importance and urgency” and computed them to a single indicator we labeled priority, but still try to leverage “real priority” we mentioned considering cost when we move to step 5 and review with ROI in mind.

Question: What about when something is not really important but is very urgent? Do we just let the deadline pass? Or just not do it?
Answer: Yes, It may be we decide not to do it since, while urgent, the impact it has isn’t worth our time – particularly in the context of higher important items – but that where using appropriate judgment in the review stage is important to make that consideration

Question: I would like to see a real example
Answer: I’ll keep this in mind for a future presentation

Question: importing Jira issues in Miro is easy enough, as well as adding labels for each of the 4 indicators. is there a easy way to import those indicator values back in Jira?
Answer: Editing the fields in Miro should sync back to Jira

Question: Mitch, do you have any suggestions for a large backlog (100+ items)?
Answer: Its totally possible to do, just not ideal – that said, if you can keep the conversation at a high level and leverage some “divide and conquer” with a group review after items are roughly placed, you’ll likely end up in a good enough place to focus a more in-depth refinement exercise on the items that bubble to the top. The goal is the help bring focus from the noise, not perfectly solve for all the items, so use that freedom to the groups’ advantage!

Question: @Tanner: What do you consider a “large group of people” when talking about a Sprint Retrospective?
Answer: I would suggest a few tweaks for groups of 17 or more, and I’ll call it 1-3-6-Silent All. Start silently, then get in groups of 3 and have the groups pick the top 3, then groups of six again picking the top 3, and finally do silent dot voting instead of the one up/one down that I described. If you have a few with same number of dots, open it up for conversation and try dot voting on just those few to see what emerges.

Question: Unfortunately, am being pulled into another meeting. I’m hopeful, like some of the earlier commenters, that there will be a recording available.
Answer: Hi Pam, thanks for joining us! We’ll be sure to share a recording via email

Question: Is this method only to increase the development speed?
Answer: No. I used my “What’s slowing us down?” prompt only to demo the technique. There’s a great number of prompts focused on other areas that can be used with this technique. I shared a few more examples of good prompts in a future slide.

Question: Do we ask everyone to participate or its voluntary?
Answer: I ask everyone to participate.

Question: I’d recommend spotlighting the shared screen, we don’t need to see the hosts on camera during most of the demo
Answer:  N/A

Question: Does it make sense to have retros every two weeks (at the end of each sprint)? I find our team runs out of things to discuss at this cadence
Answer: Ideally, teams wouldn’t wait until the retro to decide on something to tweak. They’d do so in the moment. To me, it make sense to have the retro every sprint. If the team is having a hard time coming up with things to discuss or tweak, I might get curious about a few things:

* How busy are the team members? Do they have so much on their plates that they feel they can’t experiment with better ways of working?
* What’s important to the team members about how they work together? How are those things being addressed?
* Are they quiet and compliant about how they work together? What’s not being said that would be insightful?
* How much autonomy does the team have around how they work together?
* Who typically makes decisions for how the team works together? How are those decisions made?

Question: Would you still suggest working in pairs if its a large group?
Answer:  I would suggest a few tweaks, and I’ll call it 1-3-6-Silent All. Start silently, then get in groups of 3 and have the groups pick the top 3, then groups of six again picking the top 3, and finally do silent dot voting instead of the one up/one down that I described. If you have a few with same number of dots, open it up for conversation and try dot voting on just those few to see what emerges.

Question: How exactly would a facilitator create breakouts when conducting things remotely using a tool like Zoom?
Answer: Zoom has breakouts built in. Once you’ve used it a few times, you can quickly create your rooms or you can ask a team member familiar with zoom to assist with room creation as you facilitate.

Question: What about the items that were important but did not make it into the top picks? Is it a best practice to keep them or scrap them (purposely to see if they come up again)
Answer: With co-located teams, I would usually leave them in the center of the table, but I never had a team grab for them after the fact. For remote teams, all your ideas are still on the Miro board. From my experience, if something is a good idea, it’ll either bubble up to the top that retro, or it’ll continue to come up in future retros.

Question: Could you do silent all by using voting in Miro and then stack ranking based upon the votes?
Answer: You can. Try both in different retros or with different teams and find what works best for you and for them.

Question: Can you demonstrate how the estimation and prioritization in MIRO is imported into JIRA backlog -> so that backlog is properly prioritized, items ordered with story points assigned, and all the dimension – Importance Urgency … visible in JIRA correctly?
Answer: The values should sync with Jira as you edit them on the cards (although Importance/Urgency/Priority might need to be added as custom fields). Getting the ordering to visualize correctly in Jira might require manual shuffling within Jira, unless we creatively used a system field like Rank in Jira for priority.

Question: Whats the maximum of people you would do the cards switching method?
Answer: 16. More than that, and for time, I’d use dot voting instead and then allow room for the conversation at the ideas that received a lot of votes.

Question: Could we use voting as a quick way to determine what the team thinks is the most important issue to address?
Answer: Yes! Feel free to try this technique in different ways to see what best fits your situation and your team.

Question: How is the upvote/downvote series through 8-16 people better than silent voting?
Answer: Either work great, really. Some variety is often good in a retro, and there’s information to be found with each member’s turn. With dot voting, I suppose you get all the same information, but it’s all at once instead of a little at a time.

Question: Will we get access to this deck/miro page? I love this content
Answer: Good to hear! We’ll be sharing all resources via email

Question: What are the advantages of this technique compared to voting?
Answer: Live answered,05/24/2023 11:41:43

Question: For the solution space, which techniques would you recommend Tanner?
Answer: There’s so many great ones to choose from! In many cases though, I usually mix 1-2-4-Silent All with something that doesn’t have so many “rules” or steps. For example, I’ll put one of the “winning” problems at the top of a space of the board and ask the team to get curious about how we make this even 1% better for next sprint. I’ll ask questions like “How will we know?” and “What will tell us things have improved?” and “How will our conversation look when we sit at our next retro and talk about this?” I’ll jot down their ideas and maybe dot vote for the ones they like best.

What’s important is arriving at one or two small things the team is willing to try, and I like to see if someone will volunteer to take lead on keeping us honest to those things.

Question: Tanner, your tool/technique is great and I’m looking forward to acquiring the slide deck, but the VALUE is in your narrative. Can you augment your slides with an explanation?
Answer: Great idea! Let me augment the slides with some of the language I used. I’ll try to get to those changes before you see this answer. 😉

Question: If you were running this as a retro would you do anything on a ‘what went well’ section?
Answer: Sure. You could create a prompt like, “Where are we crushing it?” or “What are we great at?”

Question: What about stating a prompt with “How might we…”? Do you consider that a bad prompt?
Answer: That depends on what comes next. What matters is asking the question so they consider the problem and not the solution. For me though, I can’t imagine a “how might we…” that doesn’t get me to think about solutions, but maybe you can.

Question: On average, how long can this technique take?
Answer: Approximately 15 minutes.

Question: Why are your bad prompts bad prompts?
Answer: Because they’re focused on solving the problems instead of identifying the most important problems.

Question: What do you recommend for the Solution Space in the retro
Answer: There’s so many great ones to choose from! In many cases though, I usually mix 1-2-4-Silent All with something that doesn’t have so many “rules” or steps. For example, I’ll put one of the “winning” problems at the top of a space of the board and ask the team to get curious about how we make this even 1% better for next sprint. I’ll ask questions like “How will we know?” and “What will tell us things have improved?” and “How will our conversation look when we sit at our next retro and talk about this?” I’ll jot down their ideas and maybe dot vote for the ones they like best.

What’s important is arriving at one or two small things the team is willing to try, and I like to see if someone will volunteer to take lead on keeping us honest to those things.

Question: How to handle this retrospective method with larger teams?
Answer: I would suggest a few tweaks, and I’ll call it 1-3-6-Silent All. Start silently, then get in groups of 3 and have the groups pick the top 3, then groups of six again picking the top 3, and finally do silent dot voting instead of the one up/one down that I described. If you have a few with same number of dots, open it up for conversation and try dot voting on just those few to see what emerges.

Question: Do you also have prompts that are more business specific? E.g., about the product?
Answer:  The recipe for the prompts remain the same: Be brief. It should be resonate. It should focus on the problem and not the solution. I’m happy to help you find some that work in your context so reach out to me at tanner@worth.am, and we’ll chat.

Question: What if the pairs/squads provide same problems?
Answer: That happens often in my experience. Have them merge it into a single sticky. Be careful though. If you see them use the word “and” as they merge, it’s likely two separate issues that they’re having a hard time agreeing on.

Question: How to handle this retrospective method with larger teams?
Answer: I would suggest a few tweaks, and I’ll call it 1-3-6-Silent All. Start silently, then get in groups of 3 and have the groups pick the top 3, then groups of six again picking the top 3, and finally do silent dot voting instead of the one up/one down that I described. If you have a few with the same number of dots, open it up for conversation and try dot voting on just those few to see what emerges.

Question: Do Team members need to move the card if they are happy with the priority?
Answer: It’s also okay to skip their turn if the like the order. This is another signal that the team has converged on proper priorities if you see several doing so.

Question: How is the size affecting priority?
Answer: It impacts priority as we consider ROI – for example, across high-priority items where several are significantly smaller, they might be where we want to focus for high-impact quick wins!

Question: Which is a good technique to do the grooming of the issues in Miro, with all the team?
Answer: Mitch’s Multi-Pass Planning is one technique to use. Example mapping is a great technique to use with Miro to refine the details of product backlog items with the team.

Question: Mitch Would you suggest using multi-pass planning within PI Planning?
Answer: I’m not very familiar with PI Planning in the context of SAFe so I cannot speak directly, but based on the high-level summary I just read, I think it could be absolutely useful. As we create plans and desire to communicate commitments and risks around them, having a forecast can key for providing data around those conversations, – and Multi-Pass Planning helps you get there, in the fast sizing exercise if you need to quickly get a rough estimate, and in the ranking related steps to make sure we prioritize and communicate where we plan to start first (and whats at risk since its lower in the stack as a result)

Question: How to do planning and retro with very un-engaged people?
Answer: I suggest starting with seeking to understand the source of the un-engaged behavior – is it because they are shy, quiet, or tired? Maybe they need individual time to think and compile their thoughts? Maybe its not interesting? Maybe they don’t feel empowered? Perhaps they don’t understand the value they have to offer? Have we made space for them? – Once you dig into these, you might better support them beyond any general advice I could give

There are a variety of activities and techniques to help engage people – like giving everyone poker chips to spend throughout the session to make sure they are not over or under engaging – or activities like “measuring confidence in our sprint plan on a scale of fist to high-five”. There are also other techniques that allow silent time to compile thoughts and allow people to more comfortably engage

Question: Prior to sprint planning, how do you usually communicate what each backlog item means so that engineers can begin to estimate in the first place?
Answer: I have a personal perspective that views “Sprint Planning” like exam day – the best way to make the exam day and easy day is to be responsibly prepared. For me that means we have backlog refinement, spikes, conversations, etc ahead of planning so within planning we can focus on setting achievable sprint goals.

Question: Mitch – our team works support and enhancements – how do you account for both in a sprint?
Answer:  I think it depends on the % of your capacity for support vs enhancements.
If you have an outsized support burden, Kanban might be a better way to manage your work – and you can still decide to keep scrum meetings you find valuabe for your iterations (like retros)
Otherwise, you might retrospect with the team how to set real, achievable goals around enhancements – in a way that takes support into account and have a strategy for what to do if we have extra time (or we need to pause on our primary goal)
You also might review if the support items are actually urgent – perhaps always, perhaps not – being able to schedule them vs being forced to react to them might allow you to better manage their capacity and impact on the sprint (admittedly this is usually rare or hard to change).

Question: 102,Can you determine Importance/Urgency/Priority before Sizing?
Answer: You could absolutely compute them first, ahead of sizing – the only additional “nice” outcome of doing it last is we do not need to resuffle the cards for an additional exercise if we compute priority last – and that means as we compute them, we could place them roughly in the order they belong

Question: How, and why do you get soooo many backlog items?
Answer: Digital backlogs make ticket hoarding a common issue. Ideally, the backlog reads like a clear story of our direction and intent – most read like mad libs 🙂

Question: I understand you’ve had prior webinars on Agile & Miro. Any chance I can get access to those recordings?
Answer: We’ll be sure to share recordings of those sessions via email

Question: I am working on a UX proposal which is similar across different tabs in a given page. Is it wise to group this into a single story or have 7-8 stories having the exact same description and acceptance criteria and the desired outcome?
Answer: Ultimately whatever works for you and the team is ok – I might view duplicate stories as a “smoke” that I’m writing stories close to the “work” and not the “outcome” – and if it is the outcome, maybe its too focused on my domain and not quite expressing the value to the customer. I tend to err on the side of larger stories that cover customer outcomes but it admittedly takes a lot of trust and support from implementing teams (since multiple people might contribute to a single ticket)

Question: Usually issues are obvious and common for all team members in our team. Therefore it is really easy to focus and summarize the problematic parts.. the level of team`s experience makes a big difference I think. But if the solution is out of team`s control, retros are like deadlocks. What do you think? Like always changing prios or badly documented requirements, what do you recommend to break these “repeating itself” retros?”,Tugba Mahcup,tugba.mahcup@rohde-schwarz.com,”Usually issues are obvious and common for all team members in our team. Therefore it is really easy to focus and summarize the problematic parts.. the level of team`s experience makes a big difference I think. But if the solution is out of team`s control, retros are like deadlocks. What do you think? Like always changing prios or badly documented requirements, what do you recommend to break these “repeating itself” retros?
Answer: I know what you mean. Check out “Circles and Soup” as a facilitation technique to help with those situations. It’s meant to help identify what’s within a team’s control, what they can influence, and what they’re unable to do anything about. I believe there’s always something the team can improve and that’s within their control, and I think giving voice to the things they can’t control so they can find the support they need is also important.

Question: Any tips for getting a team to be accountable to complete the work brought into the sprint, and not just shrugging off goals not being met?
Answer: This is a common occurrence in my experience and can be a challenging cycle to break out of.
I’ve had the most success tacking the issue on multiple fronts
1. Is leverage retrospective and 1:1 to discuss the intent of setting sprint goals and seek to understand what might be going on – is it lack of commitment? Fear to say no? Challenges due to how the team organizes around work? lack of motivating vision? Unfamiliar without carry-over creates a large process burden as we have to review and commit again to work in partial states.
2. Work with the Product Owner to make sure we’re creating meaningful goals (trying to leverage ideas of motivation from Daniel Pink’s book “Drive) – what can we sprint to produce in terms of real value, not just work to keep busy on.
3. Be explicit with the team ahead of planning and come prepared when introducing a new perspective to planning – and one that might not prioritize completing the work we touched the last sprint if it doesn’t align with our current sprint goals.

Agile Expert Webinars by Miro and Applied Frameworks

This webinar is the fourth in a series produced in partnership with Miro, where Agile experts spotlight what’s new in Agile to inspire and educate.