I doubt that you'll actually find 'the real thing' (because who wants to share their development details?) but if you search for relevant terms on YouTube you find material that comes close. E.g. searching for https://www.youtube.com/results?search_query=daily+standup has a result https://www.youtube.com/watch?v=q_R9wQY4G5I , which gives you a pretty good impression of how a daily standup can/'should' go (It's a training video where they discuss what's going on). As is clear from the title, this one is part of a small series https://www.youtube.com/playlist?list=PLBF7FCBE7E2ECF1FB Happy hunting for other videos...

No, the Product Owner shouldn't be defining the execution of work during a Sprint. At the Sprint Planning event, the Product Owner and Developers collaborate to craft a Sprint Goal, select Product Backlog Items for development, and the Developers create an initial plan for achieving the Sprint Goal and delivering the work. These three elements are the Sprint Backlog for the Sprint. The Developers are accountable for the Sprint Backlog. The plan is created "by and for the Developers". Although the Product Owner is involved in crafting the Sprint Goal and influences the selected Product Backlog Items based on ordering the Product Backlog, the Developers select the work, create the plan, and revise the plan at the Daily Scrum (and more frequently, if necessary). If the Product Owner is exercising control over the Sprint Backlog and the daily work of the Developers, that could indicate micromanaging and perhaps a lack of trust. It also indicates that the team is not self-organizing and self-managing.

First of all, https://pm.stackexchange.com/questions/26881/how-to-chose-the-right-perspective-in-user-stories . It's useful to capture a requirement from a user's perspective, but then it starts to get in the way when you start to think at the actual solution that you have to build and all the technical implications, because doing things like API changes, schema changes, etc. is not something a user cares or even thinks about. You can start with a few user stories that reflect what the user can do when you move from one book to multiple books, and then see what might be required in each case and in what order you might do them. Then, https://pm.stackexchange.com/questions/27476/making-backlog-items-independent-how-that-can-be-achieved , it just means you should try to reduce dependencies as much as possible. You will always have dependencies and features that build on each other, you just have to be mindful to not develop with too many dependencies at once (more dependencies, more problems; less dependencies, less problems). It seems you already identified the kind of changes that are needed. Now it's a matter of deciding on the order. And you decide on that by asking "what is some small change that I can introduce to keep everything working the same?" You could change the schema for example, to support multiple books. One book fits into a schema that supports multiple books. All layers above it that store and retrieve one book, don't really need to know or care that the schema could now support more. Nothing changed for them. Then you might change the export to export more books, but because nothing else changes, you will still be exporting just one book. Import will work the same because of that. Then you change the import to handle more books, and things still work. They work with one book still but now schema, import, and export are prepared to handle more books. Then you think "what is some small change that I can introduce to keep everything working the same?" You get the idea. At some point you will be making the changes that actually handle multiple books and everything you've previously built is there to handle them. So that's how you split them. The fact is that, even if you build everything in a big bang effort on a separate branch, and then replace everything in one move, you will most likely still build it in a similar way. You might pay less attention to making sure things still work after each change, since you are building things on the side, in isolation, but order and dependencies of each step might be similar. The advantage of building incrementaly is that you find out about issues earlier than with a big bang approach, where things either all work, or don't.

There's no requirement that the Scrum events that bookend a Sprint - the Sprint Review, Sprint Retrospective, and the next Sprint's Sprint Planning - all happen consecutively. Especially for the Sprint Review, it's important to schedule that at a time where the key stakeholders are able to be present and participate to synchronize and coordinate with the Scrum Team. For the Scrum Team, having all of the events consecutively can be grueling and tiring, considering the maximum timeboxes of 4 hours for Sprint Review, 3 hours for Sprint Retrospective, and 8 hours for Sprint Planning. There is value in having time for the team. Ideally, I try to have this time fall between Sprint Retrospective and Sprint Planning. However, this time isn't for development, but rather refinement. The Sprint Review and the Sprint Retrospective can generate work for the team. At the Sprint Review, the Product Backlog is adjusted, which may result in unrefined Product Backlog Items being moved up or new Product Backlog Items being added. At the Sprint Retrospective, the team identifies changes and improvements that may require effort to implement. Spending time to refine the post-Sprint Review Product Backlog and the improvements from the Sprint Retrospective would be a good use of the team's time and make the upcoming Sprint Planning more effective. Beyond refinement, holding time for non-developmental work at the time around the boundaries of a Sprint can help the team include overhead activities (like company-mandated training) or just take some regularly time off to help the team maintain a sustainable pace (a principle of Agile Software Development). In your particular case, if I were coaching the team, I would suggest that the team build their Sprint plans around making sure that the Sprint Goal is achieved prior to the Sprint Review. Any other work that will be done within the Sprint should also be done prior to the Sprint Review. Any time outside of the Scrum events between the end of the Sprint Review and the start of the Sprint Planning session would not be on building the product. Instead, I'd suggest that the team focus on refinement, training, skill building, or resting.

This is something that's a problem for my organisation. Here are some things we do to make it less problematic: Use a Release branch in source-code management (including the sources of documentation) so that future feature work can be committed and tested on the Develop branch without needing a full code freeze. Regularly review the team's Definition of Done (either as part of Retrospective, or as a separate activity) to discover activities done for release that could (should) be part of a feature ticket. Begin each story by having a Start-of-Story Conversation between the developer taking responsibility for the ticket and one or more other team members to identify what testing, documentation, policy update, approvals etc. need to take place as part of the story. This is also a good time to consider other impacts of the work, such as likely risk areas for regression. Perhaps your policy updates and training can't actually happen until your product is released. But having prepared these as part of feature work, then the release activity is reduced to gathering together all the prepared pieces for the features actually included in the release and packaging them for delivery. Don't expect the Definition of Done to be perfect after your first time updating it - my suggestion to regularly review is important. I'd suggest that you have this review after each of the next few releases; you'll find work that could have been done earlier, enabling you to release with less overhead (more accurately, with that overhead moved to be part of the feature work, getting you nearer to the ideal of release on demand). Our Start of Story Conversation uses a template in our team wiki, that has a checklist of things we should examine to double-check that the story is Ready, and that all the risks and supporting work are considered before starting development. It normally takes 2-3 developers around five to ten minutes to walk through this and arrive at a shared understanding of what's included in a story, and what needs to be complete before it can move from one state to the next. Again, it's a living document, and the items in the checklist will be specific to your team and updated as you discover (in Retrospectives) oversights that could have been asked about before starting. (Actually, we choose one of several documents because we work on more than one product, and we have an additional one for non-product work such as infrastructure updates). We still need "release sprints" in our team, but that's an improvement from taking two or more sprints to release, and we're still finding ways to move work to the left, so we haven't reached our limit as we aim to be able to release on demand.

Scrum is about collaboration, trust and empowerment. It is going to be very difficult to make people do those things. They have to want to do them. Some things I would suggest include: Try and build up trust - perhaps by giving them good advice or by being an effective facilitator of their meetings Spend time coaching - try to get them to understand why they would benefit from following the Scrum framework Use the retrospective to hightlight challenges the team faces Introduce them to teams that are successfully using Scrum If you do decide to speak with your managers, ask them to motivate the team to be more agile. Perhaps by setting agile objectives (e.g. "Demonstrate a good Scrum process") and rewarding them if they do this well.

A good place to start would be to try and work out what is motivating this behaviour. Is it that they don't feel these working practices have value? Maybe they are introverted and feel uncomfortable when collaborating? Once you have a feel for their motivation it will hopefully be easier to work out an approach.

There's no such thing as "DevOps people". DevOps is an organizational culture. Like how Agile brought the business and developers into a close, collaborative relationship, DevOps is about a close and collaborative relationship between development and operations, with the end goal of making it faster and easier to make a change and put that change into production, while ensuring the overall quality of a system. The result of a shift to a DevOps culture is the elimination of silos and hand-offs between a development organization, who is responsible for eliciting requirements and building a system, and an operations organization, who is responsible for putting changes into production and supporting (monitoring, maintaining) the system. Just like in development, there are many roles associated with operations. A few examples of operations roles include help desk or technical support staff, network administrators, database administrators, network architects, various security and incident management roles, among others. From a team's perspective, good teams moving toward agility should be trending toward being cross-functional. That means that the team, to the extent possible, has the knowledge necessary to take on work from start to end in the workflow. But some skills are highly specialized or not needed on a day-to-day basis, so it may be more about teaching the basic skills to multiple members of the team while making sure that there are sufficient experts to support the teams as needed. It doesn't necessarily mean that each team has an expert in every possible subject matter area. There's no one-size-fits all answer. In the immediate term, you need to support the teams with the people that you have. For the longer term, you need to decide which skills will be embedded on the team and which skills will exist in a shared pool available upon request. You can also identify people who may be interested in developing new skills, and how the existing experts can serve as teachers so teams can have some knowledge internally and rely on the shared pool of experts for more difficult tasks.

Such an event does not exist in Scrum. In Scrum, the Sprint Backlog is "a plan by and for the Developers". The Developers are expected to choose a mechanism (which may or may not be a board) to give stakeholders a "visible, real-time picture of the work" that is being done over the course of the Sprint to accomplish the Sprint Goal. The Developers should be the one updating their Sprint Backlog to give the Product Owner visibility into the status of their work.

TL;DR: You're Missing a Definition of Ready The whole Scrum Team should work together to define a standard Definition of Ready for both Product Backlog refinement and Sprint Planning activities, and should collaborate as a team to ensure that improperly-refined Product Backlog items (PBIs) are: a priority item at https://scrumguides.org/scrum-guide.html#sprint-review to create https://www.agilealliance.org/glossary/information-radiators/ and https://scrumguides.org/scrum-guide.html#transparency about the granularity and estimation problems to keep stakeholders informed; an urgent item at each and every https://scrumguides.org/scrum-guide.html#sprint-retrospective until the issues are resolved; are given space and priority within the https://scrumguides.org/scrum-guide.html#product-backlog itself if addressing the problem requires training, team capacity, or otherwise needs explicit inclusion in the project for scope, scheduling, or budgeting purposes; and items that aren't ready for Sprint Planning are either reduced to https://www.scaledagileframework.com/spikes/ to assist with refinement or estimation in a future Sprint, or rejected from the current https://scrumguides.org/scrum-guide.html#sprint-backlog . The rest of the answer explains how and why the Scrum framework https://scrumguides.org/scrum-guide.html#end-note , and recommends some of the things your team can collectively do about it within the defined scope of the Scrum framework. Developers Can Gate Poorly-Refined PBIs During Sprint Planning The Product Owner (PO) presents a story and there are so many open questions and loose ends that we never manage to go through more than 1-2 stories in the session. The https://scrumguides.org/scrum-guide.html#product-owner is solely accountable for the https://scrumguides.org/scrum-guide.html#product-backlog , and the Backlog Refinement event is meant to ensure that stories meet the Definition of Ready for https://scrumguides.org/scrum-guide.html#sprint-planning . Note that Scrum itself doesn't actually use or define the term "Definition of Ready," although it's commonly used by agile practitioners to describe its related activities. However, the 2020 Scrum Guide https://scrumguides.org/scrum-guide.html#product-backlog : Product Backlog items [often referred to as "PBIs"] that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller[,] more precise items. This is an ongoing activity to add details, such as a description, order, and size. Please note that the refinement event—many agilists related to standardized refinement criteria such as https://en.wikipedia.org/wiki/INVEST_(mnemonic) as the Definition of Ready—isn't actually specified as a https://scrumguides.org/scrum-guide.html#scrum-events , but the related activities are referenced enough throughout the Scrum Guide that its lack of inclusion as a formal event should probably be considered an unintended oversight. Product Backlog refinement is where questions about issues with granularity and any item-specific https://scrumguides.org/scrum-guide.html#increment should be called out. If the Definition of Ready, Definition of Done, or Product Backlog item granularity aren't sufficient for reasonable estimation during Sprint Planning then the Scrum Team should consider such stories as unsuitable for inclusion in https://scrumguides.org/scrum-guide.html#sprint-backlog for the current Sprint. Developers Should't Accept Unrefined or Inestimable Work into a Sprint The Developers are https://scrumguides.org/scrum-guide.html#sprint-planning to select the work that will be included within the Sprint, and are therefore implicitly empowered to reject work for the Sprint that doesn't meet the Sprint Goal, or that is insufficiently refinable during Sprint Planning to fit within a single Sprint within a reasonable confidence interval. Planning Poker and other consensus techniques such as https://www.lucidmeetings.com/glossary/fist-five See Also Consensus Techniques https://www.ncfp.org/knowledge/fist-to-five-voting-and-consensus/ https://en.wikipedia.org/wiki/Consensus_decision-making https://www.linkedin.com/pulse/estimation-prioritization-agile-safe-framework-samir/

Short Answer yes Detailed Answer Creating a detailed mock-up can be a waste of time if the Product Owner determines the size of effort is too high to include the story in an iteration. Risky Flow: Acceptance Criteria written Mock-up is created Team sizes story Product Owner determines that the effort of the story doesn't justify its cost. Outcome: time has been spent creating a mock-up that won't be used. Lean Flow: Draft acceptance criteria created Team roughly sizes story (t-shirt) Product Owner decides if the rough size is worth the cost of the story Low-Fidelity Mock-up is created (when justified) Acceptance criteria could likely be further refined during mockup creation Team sizes the user story Product Owner determines if the cost of the story justifies including it in a backlog

There are a lot of problems with what is going on here. The first thing that stands out is what what you describe as a team doesn't seem to be a team. https://en.wikipedia.org/wiki/Team . Although you have a group of individuals and you may have a shared goal, it seems like everyone is working on their own work as individuals. It's not a collaborative environment. A good Scrum Team is highly collaborative, creating plans and goals, executing on work to achieve those goals, and regularly adjusting their plans and actions. Story points are also relative estimates. Originally, they were a representation of ideal time and a load factor to help a team determine how much work they can achieve in a Sprint. Today, they are viewed as a measure of size or complexity. Although there may be a relationship between size and complexity, it's not a direct relationship. There can be a very complex piece of work that comes together nicely and is done quickly. There can also be very small amounts of work that require a lot of time and attention to detail to get right. If you're trying to equate points to time, I'd recommend estimating in ideal hours and figuring out how many ideal hours exist in your two-week Sprint. There would be no more arguing about if something is an 8 or a 55 if someone asserts that it would take them N hours and they are the ones doing the work. Keeping the burndown consistent is not a good reason for doing anything. The burndown is a visual representation of progress. It should reflect reality. Since each individual is estimating their own work, each individual should be able to determine the relative size or complexity of their work against every other piece of work and, from time to time, adjust their relative sizing to match their changing understanding of the work and the context. Assuming that you can't fix the underlying team issues, I'd focus on understanding why you are estimating and what you hope to achieve out of not only the estimates but visualizing the burndown. Also, I would suggest not using terms like "flavour of Scrum". Either you are implementing Scrum as its defined in the Scrum Guide or you aren't. Although implementing only some aspects of what is described in the Scrum Guide may be fine for your team(s) in your context, it's not Scrum.

TL;DR If you aren't doing software development, or working with a business or product-development model (or even just a company culture) that lends itself poorly to small, cross-functional teams, then the https://agilemanifesto.org/ or the https://www.scrum.org/resources/scrum-guide may not be your best options. However, any large-scale system that doesn't have an intense focus on integration—and therefore a cross-functional skill set at least at the organizational level—is pretty much doomed to fail. Your mileage will not vary. You present some anecdotal evidence about why your organization can't or won't do cross-functional teams or processes, and mostly point to the fact that cross-functional processes aren't necessarily cheaper, may not reduce overhead, and for various reasons make certain individuals or teams within your organization unhappy. Those things are often true but largely beside the point. Rather than argue those points, I will instead address why cross-functionality is pretty much de rigueur for any form of successful development and delivery (small or large), where it's mandated within Scrum, and some systems-thinking alternatives and further reading if you decide you want to take an alternate approach to implementing the required cross-functional integration processes to whatever it is you're actually trying to do within your organization. Cross-Functionality and Integration Must Exist, Especially at Scale In this section, I will address why cross-functionality always exists in successful systems, especially large ones. I will also address where Scrum mandates that teams be cross-functional, although you will need to do a lot of additional reading to understand some of the empirical control theory behind why it does so. I will also introduce the notion of systems thinking, which is essentially lacking from both your problem description and the solutions space you are grappling with. Cross-Functionality is (Pragmatically) a Universal Requirement for Successful Delivery Is cross-functionality a concept that bleeds in any sufficiently big software-architecture? Cross-functionality is not mandated by all frameworks, but all projects must be fully cross-functional especially at scale. This can be done in-house by having all the needed skills on one or more teams, or can be done by outsourcing specific skills or pieces of program/product delivery outside the organization, but one way or another you have to have all the needed skills somewhere in your matrix or the project(s) fall apart. Cross-Functionality is Mandated by the Scrum Framework What is the book-recommendation for doing scrum without cross-functionality? Is CF mandatory to begin with? If you plan to do Scrum, or a framework based on Scrum (e.g. SAFe or Nexus), then it is mandatory. Specifically, the very https://scrumguides.org/scrum-guide.html#scrum-team says: Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. Furthermore, attempting to redefine "Scrum" without cross-functional teams make whatever you're doing Not Scrum℠. The Scrum Guide says: The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety[.] so while you're free to adapt the framework in any way you see fit, the end result cannot be Scrum if you aren't leveraging cross-functional teams. Systems Thinking Scrum may or may not be a good fit for your organization, product, or company culture. That's fine; there are other agile and non-agile frameworks to choose from. However, what you really seem to have is an X/Y problem where you're not taking a truly systemic approach to your organizational and systems-development structure. One of my favorite authors about systems thinking and IT organizational structure is Bob Lewis. He's been writing about these sorts of topics since at least 1993, and if you https://issurvivor.com/?s=sub-optimize carefully you will find no less than 44 articles that discuss one of his most valuable phrases: To optimize the whole, you often have to sub-optimize the parts. This is core to lean and systems thinking. The goal is to optimize for the system (whatever you conceive that to be) rather than to optimize each team, department, or project. Cross-functional teams don't always optimize for organizational, budgetary, or HR concerns, and definitely don't optimize for the individual happiness of I-shaped people or the managers who hire them. Suggested Reading While there is a lot less hard science behind the Scrum framework per se, there is a lot of science backed by research and hard data behind systems thinking and the lean approach in general. If you want science and data rather than a more pragmatic approach such as Scrum (which leverages both empirically-proven and well-researched approaches without necessarily pretending to be either one in the academic sense), keep in mind that project management and systems optimization are continuously evolving fields, so any list is both subjective and potentially dated by the time you read it. That said, you should definitely read books by Drucker, Deming, Poppendieck, Lewis, and anything to do with queuing theory (if you can handle the math) to understand why successful agile principles are generally based on small teams with predictable batch sizes that have frequent inspection and integration points. Especially in larger systems, the predictable cadence of inspect-and-adapt cycles and routine integration points are typically the biggest problems organizations have when operating at scale. Of course, that also means those cycles and integration points are arguably the most important locations to place your cross-functional people and processes within the system.

Quick Summary: Periodic Downtime is an Agile Non-Issue, and Part of a Sustainable Cadence with Sufficient Slack It doesn't really matter what the developers do during this downtime because unless the downtime is something that happens every Sprint, it's just the cost of doing business the way you're doing it. Agile budgeting should be done based on expected full-team iterations* rather than on individual person-hours associated with piece-work, so this is a total non-issue unless it's a chronic problem with your https://www.scrum.org/resources/what-scrumbut implementation or estimation practices. *Example: 7 people at 40 hours a week for each 2-week Sprint is 560 person-hours per Sprint. You're either routinely (e.g. more often than not) delivering a Sprint Goal worth that per-Sprint cost, or the Product Owner, project, or client can choose to "fail early." If you're not thinking in terms of per-Sprint increments or validated learning, and are focused instead on 100% utilization, you're not just doing ScrumBut: you're doing agility wrong. That said, there's always something useful for team members to do. I provide a very large (but by no means exhaustive) list of such things in the following section. Just keep in mind the goal is for the activities to be useful for both the individual team members and the team as a whole, not just busy-work to sweep the sequential nature of your testing process under the rug. Analysis and Recommendations There's nothing left to swarm at this point. What are some activities that don't threaten the committed increment, but provide value to the overall team/release/project that Developers could do? Scrum isn't about swarming; it's about whole-team ownership of goals and the predictable delivery of incremental value. The framework is pretty non-prescriptive, and doesn't even require common agile practices like test-first development. While you're https://scrumguides.org/scrum-guide.html#end-note , I don't think that's your real issue here. I think you're experiencing an X/Y problem because you're thinking in terms of "doing all the things" rather than focusing on continuous improvement. In particular, there is always some sort of project debt that can be paid down or paid forward. Some ideas to consider include: Cross-training to improve the T-shape of your Development Team members, such as: having software developers and testers teach each other tools and techniques; having UX/UI people learn more about how these things are implemented in the project's language; having front-end developers learn more about about back-end development, or vice versa; having Development Team members learn more about business analysis or requirements-gathering; or having database developers learn more about the object-relational mappers (ORMs) the team leverages, or having them teach the developers SQL tricks that the ORM doesn't handle for them. Paying down technical debt in the form of: more https://scrumguides.org/scrum-guide.html#product-backlog ; spending time on all those great ideas brought up in Sprint Retrospectives but that no one has time for when Sprints lack sufficient slack; technical refactorings; code reviews; exploring seldom-touched or seldom-reviewed areas of the code base; writing additional unit tests; or updating developer laptops, software, and libraries. Assessing your architectural runway for: possible improvements to your CI/CD pipelines; capacity planning for upcoming requirements; or tools, processes, and systems that would improve the team's productivity. Learning spikes, such as: process spikes (e.g. "Let's try mob programming and see how that works for us!"); educational activities related to Scrum, team tools, the problem domain, or new language features; demoing that shiny new IDE someone started using, but that no one else knows much about yet; or show-and-tell where the developers get to show each other the most useful tweaks they've made or plugins they've added to their nvim, emacs, or RubyMine environments. Potentially-useful side projects (think Google's now-defunct "20% time" policy) such as: building devcontainers; replacing crufty or bloated linters with something the team likes better; building a wiki for the project; or anything else that has potential value for the team, project, or organization. Even "just learning something new" is often beneficial because stagnant developers either stagnate or leave. When you keep your team too busy to explore, learn, or work on professional development under the 100% utilization fallacy or its many variations, the organization eventually pays the price. In short, it really doesn't matter what the team does with slack time so long as it isn't excessive. All projects require slack; the trick is to right-size the amount of slack you have, and to do something constructive with excess slack. Key Take-Aways If you take only only two things away from this entire post, memorize the following points: Avoid creating busy work to reduce the visibility or transparency of your sequential testing process. Scrum (and agility in general) are about creating transparency, visibility, and predictability. Anything that reduces those OKRs is an anti-pattern. Reward, don't punish, a team for being efficient or delivering faster than planned. Success is based on outcomes, not time or effort expended, so regardless of what your organization may think piling more work on people because they finished faster than expected is the exact opposite of how to create or keep 10x teams or high-performing individuals. Slack is essential to effective processes (see pretty much all of queuing theory). If your process creates excessive slack (however you choose to define that) then fix the process; don't hide the problem or disincentivize your team to deliver ahead of schedule.

There's a difference between a Daily Scrum and a standup meeting. The Daily Scrum is one of the Scrum events and is defined in https://scrumguides.org/ . It is a 15 minute event for the Developers of the Scrum Team to look at their progress toward the Sprint Goal and determine what they will do over the next day to move closer to achieving that Sprint Goal. It's a planning event held by and for the Developers, managed by the Developers, and perhaps facilitated by the Scrum Master upon the Developers' request. In agile software development, the http://www.extremeprogramming.org/rules/standupmeeting.html . It includes the entire team - the developers, the onsite customer, the coach, and anyone else involved in the day-to-day work. Originally, everyone did stand to keep the meeting short, but that rule has been put aside by many teams. It includes both status update and planning components. Outside of agile software development, other types of teams have used similar practices to update and align the team. What you describe as a "daily standup meeting" - a meeting that could run upwards of 1 hour with 20 people that includes topics not related to your daily work - does not align with Scrum's definition of a Daily Scrum or Extreme Programming's daily standup meeting. For me, the two biggest concerns are the number of people (20 is much too big for an agile software development team) and the topics (topics should be directly relevant to all of the people in attendance). In theory, the purpose of Scrum's Daily Scrum is not to make fine-grained decisions. The guidance about meeting throughout the day often includes solving the most specific problems faced by the team and often includes a subset of the team. When you start including all, or even the majority, of the team's Developers in either decision points or perhaps in all of the work, you are moving toward https://en.wikipedia.org/wiki/Mob_programming , and the Daily Scrum becomes less useful. The Daily Scrum is most useful when people are working in individuals or pairs and need to have an opportunity to synchronize, make sure that their Sprint Backlog is reflective of reality for external stakeholders, and if there are any risks or impediments, involve the Product Owner and Scrum Master immediately. You may see some value in you and your direct colleagues meeting for up to 15 minutes once a day to carry out a true Daily Scrum. In some cases, this may replace some of the more ad-hoc "sync ups" that you are doing and give the individuals more time for focused work with less interruptions and context switching. However, there's really no problem with the ad-hoc sync ups if the team is satisfied with their performance. It may not be Scrum, but being an effective and efficient team is more important than following the rules of Scrum.

It will be a challenge, but there are a few possible approaches that can help: Combine the Scrum Master role with another role (such as an automation test engineer) - organisations that hire for combined roles will be less strict on the Scrum Master experience Look at charities and NGOs - salaries won't be as high, but they are typically a bit more open-minded in their recruiting strategy

If your Sprints start on Mondays, how can you have a Sprint start on January 15, 2022? That day is a Saturday. Similarly, if your Sprints end on Fridays, how can you have a Sprint end on January 24, 2022, since that day is a Monday? It seems like you are overthinking this. Consider how people normally allocate their time, especially your key stakeholders who you would want to be involved in the Sprint Review. It would probably be easier to tell them that the Sprint Review is every other Friday, starting at a specified time. Your Sprint Retrospective can follow that, and your Sprint Planning would be during the next working hours available. There is no need to count weekends as part of your Sprint. No one should be working, considering the Agile principle of working at a sustainable pace. If weekends are not normal working days, just ignore them.

I'm not entirely sure if that is still "project management", but what has helped me in my developer role is to actually take a day and do the work that my program is supposed to improve. This yields at least four good kinds of information: Sometimes, users of the old program are so set in their ways, that they just want the same. Just better. While actually a completely different approach to the problem altogether might be better. You will never find that out by talking to users of the old program. Sometimes, you as a programmer are frustrated by a step in their work process because you know it could be easily automated, while the users of the old program have just accepted it to a degree that they won't even mention it any more. Sometimes, when they explain their work to you, you notice that changes in their process and work routine could easily eliminate programs or part of programs they are asking you to write. I once scrapped a full feature of organizing and filing and assigning tasks by just asking why they don't just switch steps in their process around so they don't need this whole coordination software. Turns out they never thought about it. You get UX information. I once built a software that had a screen with two buttons, each of them as big as half the screen. It looked horrible. Like a four year old had accidentally clicked around in an UI builder. But it worked. For their purpose it was perfect. Because they were standing in a warehouse with thick gloves on and if they had a normal looking user interface, they would need to take the gloves off, click the tiny button, put the gloves back on and continue working. With the ridiculously huge buttons, they could move the mouse and hit them even with their thick gloves on and never needed to take them off. But that is not information you get when you sit around the requirements planning table with their foreman's boss who has not been on the floor a day in his life. Are there ways to ponder about the requirements in theory around a table? Probably. You can invent personas and play through all their tasks with your software, but it will still be a theoretical construct brought to you by people most likely one or more steps away from actually doing the work and using the program. The only way to actually get a grip on it is doing it yourself. So what can you do as a project manager? Well, resource planning is your job. Plan it so a few of your developers have the time to actually experience the thing they should improve.

A User Story is a promise of a Conversation. This https://en.wikipedia.org/wiki/User_story was said by one of Agile Manifesto authors, Alistair Cockburn*. So yes, a User Story can be a one liner. But aren't stories supposed to be specific and scoped, refined together with the developers (ready to work, to address ambiguity), and have clearly defined acceptance criteria (definition of done)? And perhaps a UX specification/screenshots/sketch drawings? These are not mutually exclusive arguments. The key is when in time each happens. The Product Manager may write a one liner - as a promise of a conversation, have this conversation with the team and then, together, to expand this one liner into a list of agreed acceptance criteria. Agile frameworks, in general, are non-prescriptive on purpose. It allows every team to explore the best way to implement it. It's sad that most places try to mimic what other places do, forgetting each company, each context, each person is unique. I read somewhere that 95% of companies use a "hybrid" DIY agile approach, which seems like a nice way of saying that "we make up the rules as we go". Our current practices aren't working for me, and I'm wondering if the problem is with me, or that the practices aren't following recommendations. This is true and happens more than it should. It's important to know, however, that this happens as people may move into customise the framework without entirely understand why the framework suggests some practices. Understanding https://martinfowler.com/bliki/ShuHaRi.html may help understand the problem several teams face: they move into Ha, before getting the Shu. Expanding on top of the known frameworks is suggested by practitioners and authors. You'll no longer be doing Scrum, of course. But you can still be agile in your own way. *There's also a https://twitter.com/totheralistair/status/897894659544031232 talking about it but the link is broken.

I have worked with Scrum teams that have included marketing people, legal people, editorial staff, technical authors and many more job specialities. I have also worked with a team where the Product Owner was an active member of the sales team. The biggest challenge with having multi-disciplined teams is there may be an inbalance in the workload on different skillsets. The marketing/sales people would often be partially committed to a Scrum team rather than fulltime team members. There would typically still be departments (like a marketing department), but the significance was reduced as the focus was on the Scrum or journey teams.