Hi,
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?
Regards,
Paul
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.