Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,293,938
Community Members
 
Community Events
165
Community Groups

This parent issue ends before its child issues

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.jira query.jpg

1 answer

1 accepted

2 votes
Answer accepted

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.

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) 

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

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,158 views 34 44
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you