Who is responsible for setting and keeping timelines?

I am curious who within your pod/team is responsible for setting and keeping to the timelines of a feature or product delivery date? In my org, this is falling to the PO of the pod, who works with the developers to get high-level estimates. They will then monitor the timeline and update the status weekly from either being On Track, At Risk, or Off Track. They will pull scope from the feature or product if the delivery timeline is going too Off Track in order to keep to the delivery date.

The developers try their best to get the tickets that they commit to per sprint, but often (every sprint) there are tickets they do not get to and they eventually fall so far behind the timeline becomes off track.

We do not have an appointed dev lead, but we do have a scrum master who thinks themselves of a dev lead. They are adamant that not delivering all tickets in a sprint and going off track is the responsibility of the Product Owner. Is this typical? I am questioning this because if feels like the issues are development related (they are having trouble writing unit tests, their tickets get sent back from QA because something was not followed to spec or is simply broken, they can’t figure out a solution) and the PO does not know technically how to help them with these issues.


We have a delivery lead specifically for this. They own the delivery timeline, while our PO owns the requirements of the work.


@MartyRoss, +1 to this. To add to it, I have a delivery lead who works with the engineers/QA etc. to get a timeline. However, as PO, I’m ultimately accountable for what happens. If something “goes off track” I need to report back to the stakeholders to ensure they understand what the status is. It’s also my job to know why something is off track. Is it due to scope creep? PO needs to shut that down and bring everyone back to the same page. Is it due to bad estimates? Fine, communicate back to stakeholders so they understand the new estimates.


@SamanthaYuan, Similar, but different… we have a PM/PO combo, so the PO manages the explicit requirements needed to meet the definition of done and keeps the PM informed who then manages stakeholder communications.


@MartyRoss, Interesting! We just have PO’s at our org. Here, Senior PO’s generally do more of the PM role, but it is otherwise the same.


Same. We call it an Engineering Release Manager but its a function of Engineering/dev.


How would you recruit for a delivery lead? where’s the separation of duties with an engineering manager? thanks!


@RohitKumar, I break it down mostly this way:

  • The Product function owns the What and Why; specific requirements and priority of them
  • The Engineering function owns the Who and How; the investigate how to do the work based on the requirements and who will do it
  • The Delivery function owns the When; while Product can indicate the priority, delivery really determines the specifics around the actual timeline of when they expect work to be done based on best estimates in coordination with the team

The Engineering manager is really overseeing the developers from a people management perspective, doing some coding, some admin etc.

The delivery lead really functions similarly to a scrum master (which we don’t have in our case), organizing and coordinating the work as it flows through the development team in order to get it to delivery.


It would help to define “responsibility of the Product Owner” in this context.

You mention that the devs “try their best” but tickets always fall off and features inevitably get cut. Who is doing the sprint planning, date picking, and capacity?

It sounds like the team is overloaded. I’d say that the responsibility falls on whomever is overloading the team and over promising on delivery date.


This is why, in general, scrum teaches that the product manager and the scrum master cannot be the same person. It’s the product manager’s job to prioritize work to be done & get as much done as possible, and the scrum master’s job to ensure that the team is meeting their commitments.

This creates some friction, which is perfectly healthy, so long as both sides of the negotiation recognize their responsibilities and are respectful of each others’ goals.


@LawrenceMartin, In absence of a dedicated scrum master, can a, say tech lead, take on that role to pro ide that healthy friction to the PM/PO?


@PriyaVarma, Yes, I mean “scrum master” to refer more to a set of responsibilities, as opposed to a dedicated role. Most teams are going to either be too small to have a person with the Scrum Master title or are mature enough to the point where you don’t need one.

In my experience, a tech lead, or a DeFacto tech lead, can absolutely fulfill that role. In fact, they’re probably the best person to do so.


This is such an important element to a functional team!


It sounds like you have a very missed expectations for how development works. No engineering team in the history of engineering teams is capable of accurately predicting what it will take to complete when they are scoping the work it is literally called an estimate for a reason.

Don’t turn into some of these big slow organizations that spend 25% of their time trying to plan accurately. Learn to accept that nearly any project will get delayed when engineering resources are required to estimate work. Include those delays in your estimates when you’re discussing the delivery timeline with your leadership.


@YuroRoman, Yes! And beyond just the “estimate” portion of the work… 50%+ of GOOD product ideas will fail. There’s no way to predict a date when a product feature will be released, because no one knows if that feature will even solve the problem. Roadmaps of product features are bullshit. The dates are bullshit.

If you think it’s the job of a PM to prescribe a roadmap of product features, then I’ve great news for you… there’s a better way.


You don’t have timeline problems when there are no timelines.


It depends, you can adjust some stuff so that finally you get close to your estimations. Not so much on each individual task, but overall sprint commitment, as the tasks compensate themselves (some take shorter, others longer than estimated).

I had a team that eventually got quite good at this.

1 Like
  1. I think the best-case practice according to me is to have a Release Train. I had a good article bookmarked somewhere but can’t find it.

Basically, you release with the same periodicity and the train waits for no one. You release everything under feature flag, so even if something is not ready - you just don’t activate it. But it’s much better for the code hygiene, easier to find bugs early and more comfortable for the team(s).

  1. Imho deadlines should be avoided at all, unless there are some really critical features that need released (ex. related to legal or company losing money, whatever). Otherwise, focus should be on delivering as much value. If you have an important bug and can’t find a fix in 1 week, spend 6 weeks but fix it, rather than tossing it aside coz of “velocity”

Lol, to hell with them. The PM/PO is the last responsible. It’s on the engineers (ideally with a dev. lead) and the Scrum Master. Why else are they there? xD

1 Like

Agree on the first two points but disagree on 3rd. If you see it looks like a combination of wrong estimation, no proper breakdown of stories and functional knowledge gap along with team velocity which can be easily fixed by a trained SM.

I’m always surprised to see how few organizations actually have scrum masters. Pretty sure I would lose my mind and probably die without mine.

We used to have a scrum master on the team that didn’t do much and I was working 65-75 hour weeks and taking PTO was impossible. My current scrum master is a godsend and I only end up having to put in 40-50 hours a week.

Scrum masters change the game.