In our current workflow we specify the maximum estimated time for an issue as the sprint duration.
The thinking is that issues are then closed at the end of the sprint.
However, clearly not every issue neatly fits into our sprint period. In which case we split the "core" issue into multiple issues over each sprint.
To me this then causes a problem as now a simple feature request has now resulted in multiple issues over several sprints which become harder to track. Comments are also then sprayed across multiple issues for the same "core" or parent issue.
So does JIRA force us to do this or is this just our own workflow preference?
Can anyone point me to some documentation on JIRA workflow best practice?
It sounds like your stories are simply too big. They should probably be Epics and consist of multiple stories where comments being split up should make sense. The other option is you could leave issues open at the end of a sprint and then roll them over to the next one.
It also sounded like a change to improve your Planning phase and Estimating. And as Boris stated, try to use Epics if you feel it will not be completed in 1 sprint. If it's a Story and is included in a Sprint, you can always pull it out from there and drag it on. The hours burned will still be in there.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs