This parent issue ends before its child issues

[Mert Öğüt]

Hi,

I am new to Jira. I hope its a single thing. I have 7 epics and each epic has 14 tasks. These tasks are attached to a single sprint. Epics have start and due dates, however tasks do not have as I want them to be started when the issues are transitioned from to-do to in progress. However, when I choose the sprint to be attached (from the issue options) they all exceed the epics due date. (As attached) I want each epic's issues not to exceed its parent epic. I guess this is happening because all of them attached to the sprint. Is there a way to overcome this? Much appreciated.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

Your Epics should not really have an end date.  They are supposed to infer their status (and hence end date) from the content of their stories, which you should be expecting to vary.  They are not items you should be estimating or planning against.

Having said that, there's nothing wrong with looking at what an Epic's end date might be to try to do some planning.  The fact that the end date Jira is suggesting does not match what you are planning for the Epic is a good indication that your planning is not right - it needs to take another look at how the stories are lining up for completion.

[Mert Öğüt]

Thanks Nic. I got your point. I am using for the construction sector, as the construction might work a bit different than the other sectors. I guess the problem is coming from the mindset as I am thinking "sprint" as the biggest work and try to divide it by adding epics and then the tasks. So imagine sprint is the building, rooms are the epics, each item in the rooms are the tasks.. So in my case I have a project which has a deadline for 6 months (sprint in my case), and then 7 unit of work(epic) which the start and end dates are fixed and each of these epics have tasks&subtasks which the start&end dates are not certain, however the duration is fixed. So as these tasks&subtasks are a part of an epic and then the sprint, I would like to see it in the scrum roadmap where I am (like in the picture attached). I do not know how this works. I would like to know what the best practice is to manage the construction projects actually. What I understood with a small search that; sprints should only be evaluated as a timeframe, that the tasks should be completed in that time (not to be considered as a big work itself) 

[Nic Brough -Adaptavist-]

Ok, that's not really going to be the best way to work here.  I don't think Scrum (sprints) are of that much use in construction - the point of Scrum is that each team delivers a usable object at the end of a sprint (something testable that shows progress in the right direction), not a complete object. 

It's an iterable thing - your sprints change according to the feedback you get from the users, and hence you can't do anything more than the most vague and variable planning.  You're light on dependencies too - scrum teams are supposed to have all the skills needed to produce.

You could argue that might work for a small construction project (such as re-arranging my house's internal non-load-bearing walls, with 2 general builders, a sparky and a plasterer, all in one team), but it's not going to work well for a large one, building anything more complex than a shed maybe.  I mean, you've probably got teams that specialise in facets of it.  In a Scrum project with many teams, you'll find you have problems working that way - for example, when the window fitters select the story "fit windows in living room" before the team that builds walls has finished most of their tasks...

I would have a quick look at two other things:

• Agile at scale (with Advanced roadmaps) - although you probably still wouldn't be veru Agile, it does have a lot of stuff to say about planning, having many teams with one goal, rolling information up to the right levels, etc.
• Kanban - it's probably a lot more suitable for Construction than Scrum is

[Mert Öğüt]

Thanks for the input and the detail explanation. Right now I am using weekly sprints. Therefore, I am able to track the weekly team progress and those will be the input for the weekly reports. So basically I have weekly sprints and I am pulling the tasks from the backlog to the active sprint and track the weekly progress. This gives me a clear picture. However, I will consider Kanban too.