[ Removed by Reddit on account of violating the content policy. ]

hi everyone! i'm a senior cs major, and we've started planning our capstone project this semester, which will continue into the next semester for the actual building/coding phase. we are a 3-person group and are trying to figure out which project board to use as we are tasked by our professors to pick one and to justify why we picked this project board.

examples given to use were: jira, github projects, trello, etc

for a capstone project, what do you guys recommend to use (preferably free and easy to navigate)? and is scrum, kanban or mix of both a better fit for 3 people?

TIA guys :)

we run 2 wk sprints across 3 projects and keeping test case status lined up with sprint progress has become like a parttime job.. spreadsheets dont scale past project #1 and confluence pages go stale the second a sprint ends.

wanna hear what agile testing tools people are using to track cases againts sprints instead of just leaning on jira tickets. anyone found something that doesnt need a dedicated QA team to run??? wahts working for you?

We have a significant digital transformation coming up and i’m trying to figure out how to resource the project management side of it

The team doing the actual technical work is internal but nobody has formal project management experience and our last attempt at something like this went sideways pretty quickly. hiring someone permanently feels like overkill for a defined project but managing it ourselves again feels risky

How have other businesses handled the project management side of one off digital projects

just curious. there's so much stuff out there that claims to help with prep/planning and most of it probably isn't worth the hype.
so what's something you use (app, feature, whatever) that's genuinely made a difference, not just "fine" or "convenient but meh"
and on the flip side, what's something you tried that you thought would help and just didn't
trying to get a real sense of what's worth people's time vs what's just marketing noise, from people who actually do this

we recently started adding ai features to our product and it is completely breaking our sprint planning normal stories are easy to estimate but ai work is experimental, half the time the team spends a sprint on a model improvement and the result is we learned this approach does not work.
our velocity looks terrible and stakeholders are frustrated because they don't see shippable increments every two weeks for scrum masters and pos dealing with this, how do you structure sprints when the work is inherently unpredictable? do you use a separate track for ai work or try to fit it into the same cadence?

Mujeres vamos aver y hacer daily scrum quien Jala conmigo

We made a free Halloween retro board generator that works off your prompts. No account needed. Choose an Icebreaker game, Check-in activity and add a Halloween themed prompt for your retro.

Not even going to try and hide that this is promoting something I made, but I did message the mods last week to ask if this was okay considering there's no sign up needed and got no answer, so I'm going to have a go anyway considering Halloween is nearly upon us. Apologies mods, delete as you wish.

First off, this is 100% free to use. You don't need an account on our platform, you don't need to login or give us any of your personal information. It's just something fun we made to test the capabilities of our MCP integration.

https://spreo.io/halloween

We've always made seasonally themed retro templates for our whiteboard product but this year we wanted to have a bit more fun with it now that our MCP is operational and we also wanted to make it available to people outside of our customer base. We got a bit carried away and made a few multiplayer games you can play within a "live widget" on the board.

So please, have a go if you're running a retro with your team this week. Hope you enjoy it.

We will most likely be doing the same for Christmas this year so if you do have any feedback, I'm always open to it.

been thinking about why the same decisions keep coming back.

a team decides something in a meeting. nobody writes down what was decided, or the notes say “discussed X.” two weeks later someone who missed it, or someone who remembers it differently, raises it again. the whole debate runs a second time, usually with new people and the same arguments, and often a slightly different outcome.

the notes themselves were never the expensive part. the repeat meeting is.

what seems to help is a decision log, kept separate from the meeting notes. not a recap. just one line per decision:

• what was decided
• who decided it (or who owns it)
• the main reason
• what would make us revisit it

that last one matters more than it looks. if the condition for reopening a decision is written down (“if signups drop below X” or “if the vendor changes pricing”), people stop relitigating it every time someone has a new opinion. they only reopen it when the trigger actually happens.

it also makes it obvious when a “decision” was really just a discussion, because you can’t fill in the owner or the reason.

do you keep a decision log anywhere, or does it mostly live in people’s heads and slack threads?

For context, I’ve worked as a Scrum Master / in Agile delivery for 5+ years and have certifications including CSM and PMI-ACP. Like many people right now, I’ve been having a difficult time landing another role in the same space.

I finally got an interview for a Scrum Master position. The recruiter initially described it as a “quick chat,” which became a 30-minute HR screening.

She joined around 15 minutes late, after I emailed to ask whether we were still proceeding.

During the interview, she appeared to be reading from a set of questions and checking my responses against expected answers. Since this was an HR screening, I expected questions about my experience and previous projects. Instead, I was asked textbook Scrum questions.

She asked me to list the Scrum events. While answering, I referred to the Sprint Review as a “demo,” which is terminology commonly used in some of the teams/environments I’ve worked in. I explained what I meant, but she kept coming back to the fact that I did not mention the review. She then moved on to questions about Scrum artifacts and other Scrum theory.

I’m not saying terminology doesn’t matter. The Scrum Guide uses specific terminology, and in an interview I should have said “Sprint Review” rather than “demo.” But surely there should be a distinction between not understanding Scrum and using terminology that was commonly used in your actual working environment.

Personally, I also think the hiring manager or someone with Scrum/Agile experience would have been better placed to assess this knowledge and determine whether my practical understanding was lacking.

The interview felt less like an assessment of whether I could actually perform the role and more like whether my answers matched specific expected terminology.

A couple of weeks later, I was rejected. Interestingly, I’ve also noticed the same position being reposted on their careers page repeatedly. With the current job market and hundreds of applications already going nowhere, experiences like this really make you second-guess yourself, even for a role you’ve been doing for years.

Mujeres vamos aver y hacer daily scrum quien Jala conmigo

Is it me, or are people lazy to read? And even worse at writing?

Have seen enough one-sentence tickets/requirements, leaving devs guessing. Have seen enough of detailed tickets, where content was not even 90% truth because of bug(fix) or change in requirements. Have seen enought bugs/mistakes due to poor reading/writing.

Nowadays I see more of semi-lengthy paragraphs made by copilot/ai, which is painfull to read, because the point can be written in fewer words/sentences.

I am starting to think that = if everybody invested in their writing skills, the world would be better. Communication better. Written stuff simpler and made more sense.

Is this a solved or solvable problem? Is there a book/guide to fix my skill issue?

Sorry if this is too long, I did took time to make it shorter.

Hi soo we’ve got 3 stakeholders from sales and ops who are supposed to help prioritize, but none of them will go into jira they say it’s confusing, which honestly fair lol so right now i export the backlog to a spreadsheet before every refinement, they comment on that, and then i manually copy their feedback back into jira after. it takes me like 2 hours every sprint

I’ve been wanting to try user story mapping instead of just a flat list anyway so the stakeholders can see the whole flow and point at where things are missing. that’s really hard to do in a spreadsheet

Options i’m looking at are mural and miro someone in our company slack said miro has a story mapping template and that you can bring jira tickets onto the board, so i wouldn’t be copying stuff back and forth anymore. if that actually works it’d save me those 2 hours every sprint planning to try it with one stakeholder first before i roll it out to all 3.

We are a 12 person b2b saas. last week our pm ran the site through ora, we got a D, and there is now a ticket to clear every failed item before the next release. llms.txt, an api catalog, oauth discovery metadata, and fixing the signup flow so an agent can get further through it without getting stuck.

I am not against any of it. I did grep september's logs for the obvious agent user agents though and found four sessions. obviously that's not a complete count, but four identifiable ones isn't exactly screaming emergency either.

meanwhile the onboarding complaints we get every week are still sitting in backlog, so I am struggling to put a sprint on this ahead of that.

how are other small teams handling it? do the cheap files now and leave the bigger journey work until there's clearer agent demand, or has anyone been burned by waiting?

Each planning cycle builds on the shorter ones while looking further into the future.

• Daily planning: Focuses on today's priorities and actionable tasks.
• Weekly planning: Includes daily planning but also looks ahead to the coming week.
• Monthly planning: Includes weekly and daily planning but looks further ahead at upcoming tasks and projects.
• Quarterly planning: Extends planning to the next three months, focusing more on projects and larger objectives.
• Yearly planning: Focuses mainly on the big vision, long-term goals, and overall direction.

The advantage is simple: The further ahead we plan, the less detailed the plan becomes. This keeps long-term goals aligned with daily actions while allowing us to adapt as circumstances change.

Video on working in Focus Cycles:
https://youtu.be/qMIhjWx9jCU

Working in Focus Cycles is another core principle of our Focus Cycles methodology. It is based on three ideas:

1. Long-term planning provides direction. Annual and quarterly planning helps us define what we want to achieve, establish priorities, and focus on the goals and projects that matter most.
2. Short-term planning drives execution. Weekly and daily planning turns broader plans into concrete actions, helps us adapt to changing circumstances, and ensures we focus on the most important tasks.
3. Alignment between different time horizons maximizes productivity. Annual, quarterly, monthly, weekly, and daily Focus Cycles should build on each other. What we do today should contribute to our weekly goals, which support our monthly, quarterly, and annual objectives.

Please share your thoughts and criticism.

Big goals can feel overwhelming. But once you break them down into smaller projects, tasks, and actionable steps, everything becomes much easier.

That's one of the core principles of our Focus Cycles methodology: the Goal Pyramid.

I made a short video explaining how it works and how it can help you become more productive.

Would love to hear your thoughts! Made video here:

https://youtu.be/ZK3FnqSrQCA

Summary:
The Goal Pyramid is one of the core principles of our Focus Cycles methodology. It is based on four ideas:

1. High-level goals provide direction. Having a clear vision and long-term goals helps us focus on what truly matters rather than getting lost in everyday activities.
2. Actionable tasks drive progress. Big goals can feel overwhelming. Breaking them down into small, concrete tasks makes it easier to get started and maintain momentum.
3. Projects connect goals with tasks. Projects bridge the gap between long-term ambitions and daily activities, ensuring that the work we do actually contributes to our goals.
4. Alignment maximizes productivity. When individual tasks, projects, and higher-level goals are aligned, everyone works toward the same objectives instead of wasting effort on competing priorities.

The idea is simple: Every task should contribute to a project, and every project should contribute to a meaningful goal.

I was recently assigned as Scrum Master (or project manager, the role is still not clearly defined) to a research team of PhD scientists, working on improving the accuracy of a core algorithm in a hardware/software product. I’m struggling, and I now I have been asked by my team lead to come up with a proposal for their workflow, so I’d really appreciate input from people who’ve worked with scientific research teams.

Main tension points:

• No commitments. The team won’t commit to deadlines or timeboxes. The research team lead’s position is that “scientific workflow is incompatible with deadlines.” When I suggest timeboxing something, the answer is that it’s impossible because “we always discover new ideas to try and have to switch to them immediately.”
• Constant priority switching. Upper management regularly comes in with requests on unrelated topics. The research lead defends these as “important” and pushes to prioritize them, so the team rarely stays on one topic long enough to finish anything.
• Distraction as an excuse. The interruptions are then used to explain why there are no results on the main goal.
• Low transparency. Meetings feel somewhat performative when I join, and tickets are vague enough that it’s hard to tell what’s actually being worked on.
• It’s not really cutting-edge research. Many of the approaches they’re trying are well-known techniques that are easy to find in existing literature. To me it looks more like applied engineering with some uncertainty, which should be more plannable than they claim.

It also seems that the lead is using my "lack of helping him" as a method of scapegoating me while being pressured from upper management after not really being able to deliver anything. The other side of the coin is that all suggestions or coaching advice I gave him, he refused, and he seems to be shielding his team from me, and from the work they are doing.

My own team lead (systems engineering) has now asked me to draft a proposal, and the two of us will present it together to the research team lead trying to push him more in the direction of actually trying something.

What I’m thinking of including:

• Hypothesis-driven experiments: each piece of work states a hypothesis, how it will be measured, a timebox, and the decision it will inform
• Idea backlog: new ideas get captured and prioritized instead of chased mid-experiment
• Prior-art check: a short summary of what’s already known before starting an experiment
• Interrupt budget: a fixed share of capacity for ad-hoc requests, with anything beyond that going through explicit prioritization
• Clear priority ownership: one person who decides what the team works on next
• Trial period: run it as an experiment for a few sprints, then review together and keep or drop what doesn’t work

My questions:

1. What would you add, cut, or reframe to make this acceptable to a skeptical research lead that seems to have had his hands untied to behave as a student without any constraints up until now?
2. How do you present a proposal like this so it comes across as protecting the team rather than policing them?
3. How to form "user stories" in a research environment? I think 2 week workable chunks really do not make sense in that environment.
4. Is Scrum even the right fit here?

Examples, templates, or war stories similar situations would be very welcome.

Thanks!

Hey devs and PMs,

I’m researching the long-term trade-offs of AI coding tools for my MBA thesis—specifically looking at whether heavy reliance on AI code generation leads to skill atrophy and unexpected late-stage project delays.

The survey is 100% anonymous and takes under 3 minutes (12 quick rating questions):

🔗 Take the survey here:https://forms.gle/62mAgdmDjAzjLhbZA

Appreciate your input and insights!

I've recently been asked to answer this question, and I'm curious what the community here thinks about it. Take methodology and framework out of the equation. If teams are able to decide what is their "best" way to work, what norms would you expect to see across all of the Agile teams in your organization? If management says "how do you know a team is an Agile Team," what would you expect to see?

And yes, I'm being asked this question and trying to answer it in a way that protects the teams and satisfies the powers that be at the same time.

Full disclosure: I'm James, and I make a chat app called Nook at Just Every. This question comes from building it.

Picture this exchange:

"Can you review the onboarding copy by Thursday?"

"Yes, I can do that."

Later the request becomes: "Review the copy, build the form, and ship it Thursday."

The first yes shouldn't silently cover the second request. A small practice: keep what was accepted, show the changed scope, and ask the person doing the work to accept the revision. They can agree, suggest a smaller slice, or need a different date. A clear reply in the same thread is enough. No extra meeting, no new tool.

It also leaves room to discuss priorities instead of treating an assignment as agreement.

Nook builds this in: only the assignee can accept a commitment, and a changed request needs fresh acceptance. It's free and open source (MIT): https://justevery.com/nook

Where does your team draw the line between a clarification and a change that needs a fresh agreement?

Over the past several years, I've been experimenting with how individuals and teams can plan and execute their work more effectively. Having worked extensively with Scrum and other Agile approaches, I've gradually developed a methodology called Focus Cycles, which combines long-term goal setting with short-term planning and execution.

Below is an overview of its main principles, organized into three areas: Agile Planning with Goal Pyramids, Working in Focus Cycles, and Agile Teams.

I'm particularly interested in feedback from people who have experience with Scrum, GTD, or other productivity methodologies.

Which principles do you agree with? Which do you disagree with? And what would you change?

I'm especially curious whether others have experimented with combining long-term planning and short-term execution through interconnected planning cycles.

Focus Cycles: The Core Principles of the Methodology

Focus Cycles is an Agile productivity methodology designed to help individuals and teams achieve their goals, get more done in less time, and reduce stress.

The methodology has three main components: Agile Planning with Goal Pyramids, Working in Focus Cycles, and Agile Teams.

1. Agile Planning with Goal Pyramids

• Know your BHAGs (Big Hairy Audacious Goals). I've seen many people working hard on projects without ever really thinking about their bigger vision for life. Knowing your long-term ambitions serves two purposes: it helps you make sure you're working on the right projects, and it provides the motivation to keep going when things get difficult.
• Break everything into actionable tasks. Big visions and ambitious projects are great, but they don't get implemented by themselves. Progress only happens when you break them down into concrete, actionable tasks that you can actually execute.
• Connect everything in a Goal Pyramid. I've seen many people maintain a list of long-term goals on one hand and a separate to-do list on the other, without a clear connection between them. A Goal Pyramid solves this by connecting your life vision to your goals, projects, and ultimately every actionable task, so you can always see how your daily work contributes to something bigger.
• Combine professional and personal goals. Your business, career, health, family, relationships, and personal finances all compete for the same limited time. Rather than planning them separately, include everything in one Goal Pyramid for your life so you can make conscious decisions about where to invest your time.
• Maintain a Second Brain. You simply cannot keep all your ideas, projects, commitments, and tasks in your head, and trying to do so creates unnecessary stress. By capturing everything in one trusted, regularly updated system, you gain peace of mind: you don't have to keep reminding yourself of everything because you know it's all there when you need it.

2. Working in Focus Cycles

• Work in short sprints. Instead of following a fixed plan for months, work in short periods with clear objectives. Short sprints allow you to stay focused, regularly review your progress, and adjust your plans as circumstances change.
• Combine long-term and short-term planning through scaled Focus Cycles. Long-term planning provides direction, while short-term planning ensures that things actually get done. Focus Cycles combines both by using four interconnected planning periods: quarterly, monthly, weekly, and daily. Each shorter cycle contributes to the objectives of the longer cycle.
• Follow natural rhythms. People already organize their lives around days, weeks, months, and years. Rather than introducing arbitrary sprint lengths, Focus Cycles uses these familiar rhythms, making planning easier to integrate into everyday life.
• Plan progressively. Planning your long-term goals in too much detail wastes time and limits flexibility. On the other hand, your daily plan needs to be very specific, with concrete actionable tasks. Focus Cycles solves this through progressive planning: start with a broad quarterly plan, use it to create a more detailed monthly plan, then plan your week based on your month, and finally your day based on your week. Because each plan builds on the previous one, you never start from scratch. Planning can often take just 5–10 minutes at the beginning of each cycle, while becoming progressively more detailed and accurate.
• Plan from the bottom up as well as the top down. Start each cycle by considering unfinished tasks, existing commitments, and work already underway. Only then add new tasks based on your larger goals and priorities. This ensures that you finish what you've already started instead of constantly abandoning existing work for new priorities.
• Plan by cycles, not deadlines. Deadlines tell you when something must be finished, but not when you'll actually work on it. Instead of assigning arbitrary due dates, decide in which Focus Cycle you intend to complete each task. Genuine external deadlines still need to be respected, but they shouldn't determine your entire planning system.
• Don't schedule all your tasks in a calendar. I've seen many people try to schedule every task into specific calendar slots, only to find that they cannot stick to their schedules. They do this because they're afraid their goals will never translate into concrete actions. But progressive planning already solves this problem: by moving from quarterly to monthly to weekly and finally daily planning, you end up with a very specific list of tasks to execute. There is no need to decide weeks in advance exactly which hour you'll work on each task. Use your calendar for meetings, appointments, and other activities that genuinely need to happen at a specific time, and use Focus Cycles for everything else.
• Review, learn, and adjust every cycle. At the end of each cycle, review what you accomplished, what remains unfinished, and what could be improved. Use these insights to adjust your plans for the next cycle rather than blindly following an outdated plan.
• Make time for recovery. Each Focus Cycle should also include time for rest and recovery. In your daily cycle, this means getting sufficient sleep; in your weekly cycle, it means taking time off, ideally over the weekend. Sustainable productivity requires balancing focused work with regular recovery.

3. Agile Teams

• Work in small, self-organizing teams. Keep teams small, ideally around 4–10 members, and give them the autonomy to organize their own work. The people doing the work should have meaningful responsibility for how it gets done.
• Use empowered product managers. Give one person clear responsibility for coordinating product priorities and the team's working process. Combine the traditional Product Owner and Scrum Master responsibilities instead of creating unnecessary management roles.
• Make everyone's work transparent. Everyone should be able to see what team members are planning, currently working on, and have completed. Use a shared structured task list and simple progress visualizations.
• Make individual commitments. Every team member should commit to specific tasks rather than relying only on collective team commitments. Everyone should know exactly what they are expected to accomplish, and at the end of the cycle it should be clear who completed what.
• Use daily plans instead of mandatory meetings. Daily stand-up meetings are often impractical for distributed teams working in different locations and time zones. Instead, ensure that every team member creates a daily work plan and makes it visible to the whole team.
• Measure both work and results. Don't evaluate team members solely by final outcomes. Also consider the actual tasks completed and the work performed, since valuable efforts don't always lead immediately to measurable results.
• Coordinate teams through scaled cycles. Larger organizations can combine several small teams into a superteam. Coordinate goals and planning monthly across the larger group, while individual teams plan and execute their work weekly.

4.1. People Are Overworked and Burn Out

Problem: People work too much, don't get sufficient sleep, work through weekends, and don't take proper vacations. Eventually, they become exhausted and burn out.

Solution: Work in Focus Cycles. Every cycle has four phases: planning, execution, review, and recovery. As we know from sports, recovery is essential for maintaining performance. The daily cycle includes sufficient sleep, the weekly cycle includes a weekend, and longer cycles should include vacations.

4.2. People Work Without Seeing the Purpose

Problem: People work hard on projects without knowing how these projects contribute to their bigger goals in life. They lose motivation because they don't see what they are working toward.

Solution: Use a Goal Pyramid. Every actionable task should be connected to a project, and every project to a bigger goal. This way, you always know why you're doing something and how it contributes to your overall vision for life.

4.3. People Have Big Goals but Never Take Action

Problem: People dream about starting a business, becoming financially independent, or improving their health, but never translate these ambitions into concrete actions. Years go by without meaningful progress.

Solution: Break every goal and project down into actionable tasks. Often, people procrastinate simply because they haven't figured out exactly what they need to do next. By separating planning from execution and defining the next actions beforehand, getting started becomes much easier.

4.4. Task Lists Are Badly Organized and Disconnected

Problem: Backlogs often mix huge projects like "Launch a product" with tiny tasks like "Send an email."

Even worse, many people maintain several disconnected lists. They have one list of long-term goals, another list of projects, and another to-do list with actionable tasks. But there is no clear connection between them.

Solution: Organize everything into one Goal Pyramid. Start with your long-term goals, identify the projects needed to achieve each goal, and then break these projects into tasks and subtasks.

This way, everything is connected. You can always see how each actionable task contributes to a project and ultimately to your bigger goals.

Of course, this creates a huge task list. That's why Focus Cycles divides the work into quarterly, monthly, weekly, and daily plans. Instead of looking at hundreds of tasks, you focus on the much smaller list of tasks planned for today.

4.5. Task Lists Are Badly Organized

Problem: Backlogs often mix huge projects like "Launch a product" with tiny tasks like "Send an email." Other people have long-term goals in one list and actionable tasks in another, without any connection between them.

Solution: Organize everything into one Goal Pyramid: long-term goals, projects, tasks, and subtasks. Every task has its place and is connected to a bigger goal.

Of course, this creates a huge task list. That's why Focus Cycles divides the work into quarterly, monthly, weekly, and daily plans. Instead of looking at hundreds of tasks, you focus on the much smaller list of tasks planned for today.

4.6. People Constantly Worry About Other Tasks

Problem: At work, people think about personal responsibilities. At home, they think about unfinished work. They constantly worry about things they might have forgotten and find it difficult to concentrate or relax.

Solution: Use a Second Brain that combines all your professional and personal tasks into one trusted system. Organize everything and assign tasks to realistic planning cycles.

Once you know that everything is captured and planned, you don't need to keep everything in your head. You know what you need to do today and that your other responsibilities are included in your plans. This creates peace of mind.

4.7. Long-Term Plans Are Too Rigid

Problem: People spend too much time creating detailed long-term plans. When circumstances change or assumptions turn out to be wrong, their plans become outdated and have to be completely revised.

Solution: Avoid detailed long-term planning. Keep long-term plans broad and flexible, and plan the immediate future in much more detail. This allows you to adjust quickly when circumstances change without having to redo your entire plan.

4.8. Short-Term Planning Lacks Direction

Problem: People focus only on today's tasks or the next sprint without considering their long-term goals. They get many things done but don't necessarily make progress toward what really matters.

Solution: Use cascading Focus Cycles: quarterly, monthly, weekly, and daily. First plan the quarter, then the month based on the quarter, the week based on the month, and finally the day based on the week.

This combines long-term direction with short-term execution. Each plan becomes more detailed, but always remains connected to the bigger goals.

4.9. Story Points Are Difficult to Understand

Problem: Story points mean different things in different teams. Five story points in one team might represent a completely different amount of work in another. This makes communication and coordination across teams difficult.

Solution: Estimate work in hours, a unit everybody understands.

One argument for story points is that they don't depend on the specific person doing the work. But we can achieve the same thing with hours by estimating how much time a task would take an average person with the relevant skills.

This makes estimates understandable and easier to compare across teams.

4.10. Planning Is Either Too Top-Down or Too Bottom-Up

Problem: Some teams constantly select new tasks based on big goals while ignoring unfinished work. Others only work through their backlog without checking whether these tasks still contribute to their bigger goals.

Solution: Combine bottom-up and top-down planning, in that order.

First, look at the tasks you already know need to be done: unfinished tasks, existing commitments, and tasks related to work from the previous cycle. Plan these first, while leaving some capacity for new work.

Then look at your bigger goals and decide what additional tasks you want to include.

This way, you maintain continuity in your work while still making progress toward your long-term goals.

4.11. Deadlines Don't Tell People When to Work

Problem: People set deadlines without planning when they actually need to start working. A deadline tells them when something should be finished, but not when to do the work.

As a result, people often realize too late that a deadline is approaching and they haven't even started. When they miss it, they simply move the deadline to another date.

Solution: Don't plan your work around arbitrary deadlines. Instead, plan when you actually want to work on something, using progressively shorter Focus Cycles.

First, ask yourself whether you want to work on a task during this quarter. At the beginning of the month, decide whether you want to do it this month. At the beginning of the week, decide whether it belongs in this week's plan. And finally, at the beginning of the day, decide whether you want to work on it today.

This way, you progressively narrow down when the work will actually happen without needing to set an artificial deadline. Genuine external deadlines still need to be respected.

4.12. Calendar Planning Creates Constant Rescheduling

Problem: People fill their calendars with tasks days or weeks in advance. As soon as one task takes longer than expected, the entire schedule becomes unrealistic.

They then spend their time moving tasks around instead of getting work done. Their overcrowded calendars also become another source of stress.

Solution: Stop scheduling every task into your calendar. The reason people do this is understandable: they want to make sure that their plans actually turn into actions.

But assigning a specific day and hour to every task, especially weeks in advance, creates a level of precision that is usually unrealistic.

Focus Cycles achieves the same objective through progressive planning. You start with a broad quarterly plan, narrow it down to the month, then the week, and finally create a specific daily task list.

This gives you a clear plan for what to do today without having to predict exactly when every task will happen weeks in advance. Keep the calendar for meetings, appointments, and activities that genuinely need to happen at a specific time.

I have read "Deep work" and "Getting things done", sometimes I open scrum.org to think about basics, and with this post I would like to ask what excellent books are there about agile, scrum, kanban, healthy development practices and valuable soft skill books, similar to level of "Deep work" and "Getting things done" books? Which books would you greatly recommend?

Hi all, I'm hoping to get some advice from people further along this path.

I'm a certified SAFe RTE, currently about 6 months into the role on a ~60-person ART in UK financial services. Before that I was the PMO on the same programme, but in practice I was already doing a lot of the RTE work: running programme RAID, facilitating PI Planning and pushing cross-team dependencies through to resolution. Before that I had PMO and delivery roles at a Big 4 firm.

Now that I'm looking at my next move, I'm struggling to find roles actually titled Release Train Engineer. Agile Delivery Manager roles are everywhere, though, which makes me wonder whether RTE work is often advertised under different titles or whether the market is just small right now.

A couple of things I'd really value input on:

Is Agile Delivery Manager a good next step?

How should I position my PMO-era PI Planning and RAID experience alongside my official RTE time?

Any honest advice is appreciated