Hello everyone!

I'm looking for people currently managing projects across tools like Jira, GitHub, Slack, Notion, spreadsheets, etc.:

I'd like to receive your feedback on things like:

• What do you still have to check manually across multiple tools?
• What information is surprisingly hard to get?
• What tends to fall through the cracks?
• What do you wish was automatically surfaced or summarized?
• If you could magically add one cross-tool functionality, what would it be?

Interested in both small annoyances and bigger workflow problems.

Would love to hear what your ideal setup would look like.

thank you for your time and have a great week!

I’m a Scrum Master working with a software development team, and after our latest retrospective I’m seriously questioning whether Scrum is still helping us or whether we are maintaining the framework mostly because it is our established way of working.

I’d especially love opinions from both Kanban practitioners and very orthodox Scrum people, because I want someone to challenge our reasoning rather than simply confirm that Kanban sounds better.

Context

We work on an academic management system with many different modules and stakeholders/user areas.

Our Sprints are two weeks long.

Over time, the team has started working on several modules in parallel. One Sprint might heavily focus on Module A, the next Sprint on Module B because it became more urgent, and two Sprints later we return to Module A.

This is creating a continuity problem.

From the user's perspective, they asked for Module A weeks ago and eventually ask:

"Why isn't this finished yet?"

From the team's perspective, the answer is:

"Because it wasn't actually our focus continuously during those weeks."

During our latest retrospective, the team explicitly raised that they feel we are constantly switching context and that the Sprint boundary sometimes creates an artificial sense of starting/stopping work rather than helping us finish what we already started.

Another important point: we already use WIP limits.

So this isn't simply a case of "you need to stop starting and start finishing." We've already been experimenting with limiting WIP and analyzing how much simultaneous work the team can sustain.

Planning and commitment are becoming another pain point

One of the strongest comments from developers was that sometimes the sequence feels like this:

Request → commitment → analysis of how to build it

instead of:

Request → analysis/discovery → conversation between PO + Developers → decision/commitment → development

They feel that by the time they are properly discussing how something should be implemented, there is already an expectation that it will be done.

We discussed shared responsibility here.

The PO needs to involve Developers earlier and ask what is actually viable before creating expectations with stakeholders.

At the same time, Developers acknowledged that they also need to become better at saying:

"No."

"Not yet."

"We need to analyze this first."

or:

"We could commit to X, but not Y."

So I don't see this as simply a PO problem.

We also have a stakeholder/Review problem

Users request developments and put significant pressure on the team because something is supposedly urgent.

We develop it.

Then Review arrives... and sometimes those same users don't attend.

So now we need another meeting on another day to actually get the feedback we needed from the Review.

This has started a discussion around whether we're becoming too focused on maintaining the Scrum calendar rather than optimizing for actual stakeholder feedback.

For example, right now we're discussing a schedule that could look like this:

Thursday: development cut-off
Friday: Sprint Retrospective
Monday 10:00: Sprint Review with stakeholders
Later Monday: Sprint Planning

This obviously alters the usual sequence of Sprint events.

The reasoning is practical: Friday may work better for the team's Retro, while Monday gives us a much better chance of getting stakeholders into the Review.

But then the Scrum question becomes interesting:

If we "close" development on Thursday and Retro on Friday, but the Review is Monday and Planning happens afterward, where exactly does the Sprint end?

Are we creating an artificial "cut-off" that has no real meaning in Scrum?

Would an orthodox Scrum interpretation simply say:

Review → Retro → next Sprint Planning, and stop trying to rearrange the events around stakeholder availability?

Or is adapting the calendar reasonable if it results in substantially better stakeholder participation?

I'm genuinely interested in the strict Scrum interpretation here.

The team is now asking about Kanban

The Developers — and even the PO — have repeatedly mentioned that they would prefer something closer to:

Prioritized backlog → available capacity → pull next work item → finish → pull next item

instead of spending significant time every two weeks deciding how many work units we are going to "commit" to.

Their argument is essentially:

"If the backlog is already prioritized and we have a WIP limit, why don't we finish something and pull the next highest-priority ready item?"

They believe this could give them more continuity and reduce the feeling that every two weeks we reset/reorganize the work.

One concern I raised during the Retro was individual productivity comparisons.

I explicitly told them:

"If we move toward pulling work continuously, I don't want this turning into 'I completed 20 work units and you completed 12', or developers competing to pull more work."

The team strongly said they don't want that either.

My position would be that work units remain a planning/flow tool and never become an individual productivity metric.

Another issue: we start new developments before properly finishing existing ones

This also came up very strongly.

We have several important modules/products currently competing for attention, and during the Retro we actually created a global priority order.

The team is basically saying:

"Can we please finish more of Priority 1 before opening Priority 4, 5 and 6?"

This is one of the reasons Kanban is becoming attractive to them.

We are also considering changing how we manage stakeholder expectations

Instead of a stakeholder asking for something and immediately creating an expectation of a functional development, we discussed using:

Request → discovery/analysis → mockup or visual proposal → stakeholder feedback → functional development

when appropriate.

In other words, sometimes our first commitment should be:

"We'll show you what this could look like."

rather than:

"We'll build it."

We also want waiting for stakeholder feedback to become explicitly visible in our workflow rather than having development appear "unfinished" while the team is actually waiting several days for someone to validate something.

So now I'm stuck between three possibilities

1. Keep Scrum and fix our Scrum implementation.

Maybe Scrum isn't the problem at all.

Maybe our actual problems are too many concurrent initiatives, weak refinement/discovery before commitment, stakeholder availability, priority changes and poor expectation management.

2. Keep Scrum but deliberately introduce more Kanban practices.

We already have WIP limits, but we could go much further with flow management, pull policies, explicit workflow states, aging/cycle time, blocked/waiting states, stronger policies around when new work can enter, etc.

Then after a few Sprints ask:

"Is the Sprint still providing value?"

3. Actually move to Kanban.

Remove the artificial two-week commitment boundary and manage work through continuous pull, explicit policies and flow metrics, while keeping useful cadences for retrospectives, replenishment, stakeholder feedback, etc.

I'm deliberately resisting jumping straight to option 3 just because the team is frustrated with Sprints.

I want us to understand whether Kanban actually matches the nature of our work better or whether we're expecting Kanban to solve organizational problems that will follow us regardless of framework.

My questions for you

For the Scrum purists: what in this story makes you think "your problem isn't Scrum, you're just not using Scrum effectively"?

For Kanban practitioners: what signals here genuinely suggest that Kanban might be a better fit?

Would you experiment first with Scrum + Kanban before considering dropping Sprints?

What would you measure during that experiment to make the decision based on evidence rather than preference?

And what do you think about the proposed event schedule:

Thursday cut-off → Friday Retro → Monday Review → Monday Planning?

Is that a reasonable adaptation, or are we breaking an important inspect-and-adapt feedback loop by holding the Retro before the Review?

Finally: if you were the Scrum Master in this situation, what would you change first?

I'm completely open to being told that I'm overcomplicating this, that we're doing Scrum badly, that Kanban would fit better, or some combination of all three.

I mostly want to understand what problem we should actually be solving.

Measuring a team’s throughput can be useful. But throughput of what?

High throughput does not guarantee that you are creating value. It is only a leading indicator — not a measure of value itself.

A leading indicator is a clue that you may be moving in the right direction. It has to be interpreted alongside health metrics and lagging indicators that show whether meaningful outcomes and value are actually being created.

Ultimately, the best measure is the value created compared with the money spent. That could be revenue generated, but also another outcome that matters to the organization: children vaccinated, people lifted out of poverty, and so on.

But as an early signal, what should throughput be based on?

I have tried several approaches. So far, my preferred one is the number of acceptance criteria completed per week.

Of course, that only works if the team knows how to write and use acceptance criteria properly. A well-written acceptance criterion should define how to validate the expected user or business value, rather than merely describe a technical function. It should also be solution-agnostic.

What do you think?

The brightidea pricing structure is built on an app model where each capability requires its own subscription

Starting cost looks reasonable and then the program grows, a new department wants challenge management, another needs portfolio reporting, and each one is a separate line item

Budget predictability goes out the window the moment the program expands past the initial use case

Noticed something after comparing how two different tickets got handled by whoever picked them up, one with a persona-style AI prompt ("act as a senior backend developer and implement this"), one with an AI prompt built directly from the ticket's actual acceptance criteria, spelled out as explicit rules instead of an implied identity.

The acceptance-criteria version produced tighter, more predictable output almost every time. Not because the model got smarter, because there was less left for it to infer. "Act as a senior developer" leaves the model guessing what "senior" means for this specific task, what to prioritize, what the team's actual constraints are. Acceptance criteria don't leave that gap, they're already the operational definition, this input, these rules, this output, we just don't usually think to hand them to the model directly instead of translating them into a vaguer persona-style prompt first.

Feels like something a lot of AI-assisted teams are missing without realizing it: the artifact that makes a ticket "ready" for a human, clear, unambiguous, testable acceptance criteria, is close to exactly what makes a prompt reliable too. Vague tickets produce vague AI output for the same reason they used to produce inconsistent human output, the ambiguity has to get resolved by someone, and it defaults to whoever's holding the ticket making their own judgment call, silently, on your behalf.

Wrote up the broader version of this persona vs. operational-definition distinction here, mostly written with code review in mind but the acceptance criteria parallel kept coming up while I was thinking about it: https://medium.com/@nagatomopedro05/act-as-a-senior-developer-is-the-worst-prompt-you-can-write-9f1577493cd3

I’m a Product Owner / Product Manager with 10+ years of experience building, managing, testing, documenting, and improving digital products.

I’ve worked across very different industries, including:

Hotel booking & reservation platforms
Online gaming
E-wallets & digital payments
Merchant applications
Web & mobile platforms
Backend systems, APIs & integrations

I’m comfortable working from the customer interface all the way down to the backend process.

You can hire me as:

Product Manager / Product Owner

• Product requirements & specifications
• User stories & acceptance criteria
• Backlog & roadmap management
• Feature planning & prioritization
• Stakeholder coordination
• End-to-end product ownership

Scrum Master / Agile

• Sprint planning
• Backlog refinement
• Agile ceremonies
• Team coordination
• Removing blockers
• Delivery tracking

Technical Writer

• Technical documentation
• SOPs & process documentation
• Knowledge bases
• Product documentation
• User guides
• Requirements & specifications
• Training materials

Software QA / Tester

• Functional & regression testing
• End-to-end testing
• UAT
• Test cases
• Bug reporting
• API/backend workflow testing
• Customer journey testing

What I'm looking for:

100% Remote
Full-time — minimum 8 hours/day
$20–$30 USD/hour

I'm open to Product Manager, Product Owner, Scrum Master, Technical Writer, Software Tester/QA, or hybrid roles.

If your company needs someone who can own a product, understand the technology, communicate with the team, test the work, and document everything clearly — I'm ready to jump in and start asap.

Send me a DM and let's talk about what you're building.

I was a developer up until last year, when I was hired as a Scrum Master...at a huge pay cut. I had started feeling like development just wasn't for me anymore...like the demand of keeping up with changes was outpacing my ability to do so.

I had been doing a lot of Scrum Master duties at that job, mostly to keep myself motivated. I really took to it, earning several certifications from the various bodies involved in such things.

This last job was...interesting. They talked a big game on Agile, even titling the position "Scrum Master". However, the consensus among the SMs was that it was actually 90% Project Management (which I do not have the training, and did NOT sign up for).

I now see the same thing reflected in a lot of job listings, which start out with the title and duties of an SM, but quickly mutate into obvious PM duties.

I can't actually retire just yet for financial reasons, and a handful of medical issues keep me from picking up any in-person, low-level jobs (i.e. - store clerk, etc.), but I'm not certain I care. I'm still applying for similar tech jobs, but I can't expect that I'll last long at whatever the next job is.

Does anyone have suggestions for a job that is middle ground on this? Something where your responsibilities are in a smaller circle, but still requires someone with my education, training, and intelligence?

One question from a recent leadership workshop stuck with me:

Should leaders be judged only by the results they deliver, or also by the people they leave behind?

Imagine a Team Lead who consistently achieves business goals and delivery targets.

But over time, multiple Scrum Masters working with them become exhausted, lose motivation, or decide to leave.

Is that a leadership problem?
Or is it simply what high performance looks like?

Curious how leaders, engineers, Scrum Masters, and managers would view this situation. 👇

We’re juggling multiple clients with different support tiers and time zones in one JSM queue, and keeping track of who gets what SLA is getting messy.

How are you guys setting this up in Jira so techs aren't just guessing? Native hacks or apps?

im trying to work in loops now instead of doing everything at once. quick research, build, then push distribution until 20-100 real people have actually touched the thing. their feedback + the metrics show me what needs fixing, so thats what the next building phase is. then distribution again, and it just repeats.

inside a loop the split is roughly 20/80 building to distribution, then it flips when the feedback lands. the rework im in right now started exactly like that, a user told me the service does what it promises badly (not a fun message to read btw), and thats basically what im rebuilding around now.

anyone else work in cycles like this? or do you run building and distribution in parallel every day? LMK if there other/better workflow) Plz:)

www.eddyflow.io is all about teaching the concepts of Kanban through game play and simulation.

It’s got 3 modes - game mode where you control value selection, wip limits, and how work gets done with the aim of making the most money.
Simulation mode lets you design a team, a Kanban board, and how they operate with real time flow metrics.
And replay mode lets you upload your team data so you can replay their delivery and flow metrics.

All free to use.

I am writing the functional requirements, non-functional requirements, and product backlog for my graduation project.

Should the requirements and user stories mention the specific technologies used, or should they remain technology-independent, with the technologies explained later in the software architecture or technological choices section?

For example, should I write:

- “The system shall store alerts in Firestore and cache analytical data in Redis.”

Or should I keep the requirement more general:

- “The system shall persist alerts in cloud storage and maintain a fast-access analytical data store.”

Then, in the technical design section, I would explain that Firestore was selected for cloud storage and Redis for the analytical data store.

The same question applies to user stories. For example, should a user story mention technologies such as Redis, PostgreSQL, Firestore, or a specific framework, or should it describe only what the user needs and why?

How do you visualize or track the org that represents cross-functional delivery teams versus the often functionally driven org chart?

I've used Excel which is hideous, I've seen PowerBI implemented.... I've heard of OrgVue but never used it. I have seen Miro/Mural used for this.

Anything else scrum masters or RTEs or program managers are using?

I am working as an associate SDET which is a fresher position. I have a problem. I say yes to every idea my manager has (he's also a dev) even though they are bad. Now whenever I speak with my senior about those ideas in detail then I come to realise how bad some of the ideas are like building a AI UI test executor but we already have a framework that we were planning to add coverage for for customer agnostic tests (will contain pw ui tests). This agnostic approach is way better compared to the one my manager was suggesting but I didn't think about it at that moment nor about this, nor about regression, version controlling etc.. what should I do to improve this. The senior said he expected better from me.

I keep noticing versions of the same problem.

An exec asks how many customers actually asked for something, and it turns into an hour of digging.

Sales says we lost a deal because of a missing feature, but nobody really knows if that came up in other lost deals too.

Something got shipped six months ago because of customer feedback, and now someone asks if it actually helped, but the original feedback is buried somewhere.

Or you inherit a roadmap and half the items have no real trail of why they were put there in the first place.

Feels like the actual customer evidence gets scattered or lost pretty quickly once it moves between support, sales, product, Slack, tickets, calls, etc.

Curious if this is a recurring problem for you, or if you have found a good way to keep the context attached to the decision.

Retrospectives can identify a real process problem and still produce an action that disappears once the next sprint fills up. What turns the discussion into durable follow-through without making the retro another status meeting? A useful action seems to need an owner, a small observable change, a review date, and a place in the normal work system rather than a separate notes document. How do you handle actions that need several sprints, depend on another team, or reveal that the original experiment did not help?

I've seen versions of this across a few client engagements, so this isn't one company's story or a single case.

One team gets enough room to work differently. Results improve. Leadership gets excited and decides to "roll out the model." That usually turns into templates, ceremonies and a playbook for everyone else.

Then the next teams run into completely different problems. One is waiting on security reviews. Another can't get usable test data. Somewhere else, every decision depends on a manager whose value has long been tied to approving things. Copying the pilot team's process doesn't really touch any of that.

The better examples I've seen treated the pilot as evidence that a different operating model could work, not as the operating manual. They kept a few principles: decisions closer to the work, blockers made visible, controls automated where sensible, and teams sharing things that proved useful. The implementation stayed local because the constraints were local.

Oddly, the technical sharing was often the easier part. A script or deployment template spreads because people can use it immediately. Asking a long-standing approver to become someone who removes blockers is different. That's a change in status, incentives and professional identity, not a new line in a role description.

And it can unravel quickly. One failed release or uncomfortable audit conversation and leadership starts asking for the old gates back.

I'm not even sure "scaling" is the right word. In practice it looked more like growing capability one constraint at a time. Messier than a rollout, but probably more honest.

For people who have taken this beyond the first team: what did you standardize, and what did you deliberately leave local? What stopped the organization from restoring the old controls after the first wobble?

Hey, 👋

I’ve been building SprintDesk — an all-in-one modern workspace for agile teams to manage sprints, tasks, time tracking, and team attendance in one clean dashboard.

We just opened early access, and I’d love for you to check it out and share your honest feedback!

🚀 Try it out here (Free):

👉 https://sprint-desk.com

Let me know what you think once you take a spin! 🙌

I'm transitioning into Agile/Product Ownership and I'm trying to be strategic about which training is actually worth my time and money.

I currently have:

• CSPO (Certified Scrum Product Owner)
• ICP-BAF (ICAgile Business Agility Foundations)

I'm considering taking ICAgile ICP-APO (Agile Product Ownership).

The reason I'm considering it is that I feel like there is still a gap between understanding Scrum/Product Owner terminology and actually understanding how to perform Product Owner work — particularly around product discovery, product vision, strategy, outcomes, prioritization, customer/stakeholder needs, and connecting all of that to the backlog.

Before I spend the money, I'd really like to hear from people who actually work in Agile/Product roles:

Do you think ICP-APO would add meaningful skills beyond CSPO + ICP-BAF, or would it mostly be redundant?

If you already have experience hiring or working with Product Owners, I'd especially appreciate your perspective:

• Would ICP-APO make a candidate more credible?
• Does the material teach practical skills that CSPO generally doesn't cover?
• Would you recommend spending the money on ICP-APO, or would I be better off building a product portfolio/project and getting hands-on experience instead?
• If you were in my position, what would you do next?

I'm not looking to collect certifications just for the sake of collecting them. I'm trying to figure out what would actually make me better prepared to do the job and more competitive for an entry-level/associate Product Owner or Product role.

I'd appreciate honest feedback, including if you think I should skip ICP-APO entirely.

I’ve led a department-wide Agile transformation across 100+ people, which took around a year to implement. Since then, I’ve found that my workload has gradually started to dry up.

These days, I’m increasingly doing administrative work, reporting, and helping Product Owners structure their work through Scrum ceremonies. I still provide delivery oversight and govern the ways of working I originally put in place, but the more substantial transformation work has largely been completed.

There also doesn’t seem to be much opportunity for further growth. Now that the transformation is done, management doesn’t appear particularly interested in developing or expanding my role.
I’ve therefore decided to leave. Does that sound like the right decision?

More broadly, how do people build a sustainable long-term career within an organisation in an Agile transformation role? It sometimes feels as though these roles have a fairly short shelf life - perhaps one or two years - because once the transformation has been embedded, the role naturally becomes less necessary.

Curious how other engineering managers handle this.

Let's say a project was expected to take 3 weeks but ends up taking 5.

When someone asks "Why did it take longer than expected?", where do you actually look?

Do you:

• Look through Jira/Linear history?
• Check sprint/velocity data?
• Go through Slack/messages?
• Look at PRs/commits?
• Go through standups/status updates?
• Ask the people who worked on it?
• Some combination of these?

And how easy is it to reconstruct the answer?

I'm particularly interested in the difference between knowing that something was delayed and actually understanding why it was delayed.

Curious how this works in your teams.