I'm having a conceptual problem with Jira Agile and hope someone has a good hint for me.
The way it's used
We are using Jira Agile with story points since to us, this abstract value appears better to measure velocity than actual time spent. At the same time, we are using subtasks to describe the work that needs to be done in order to create a feature (the parent task).
As an example: The feature (parent task) is "Playable character" and the subtasks are concept art, 3D model, texture and so on. That way, we can break the feature down to specific work and can easily track the feature's budget spend in Tempo.
Jira gives us an interface to do story point estimations for tasks, but not for subtasks. As a result, a feature isn't necessarily implemented 100% in one sprint (e.g. because it's still in QA and thus, not yet "done"). So if e.g. 90% of the work for one feature has been done in one sprint, it is not reflected in the burndown chart, since the respective feature is still not set to "done". This is a case we often have and kind of goes against the idea of using a burndown chart to track velocity. We've actually burned down a lot of the respective user story or feature, but the chart says 0.
Any strategy on how to deal with that issue?
This is a much discussed topic, but points are only estimated at the story level for the whole effort, including all testing.
There is no value to the end user until a feature is full designed, coded and tested, and stories reflect that.
You can use Epics (very large stories) to span multiple efforts and break out stories that deliver smaller (complete) deliverables within the larger feature.
The idea of stories carrying through is common, and for larger stories it is common for most of the burndown to occur late in the sprint.
It wouldn't be troublesome if the stories were completed towards the end of the sprint. The burndown chart wouldn't be optimal, but that's irrelevant anyways. But if they carry over to the next sprint despite the fact that just one out of ten subtasks is yet to be completed, it destroys the idea of velocity tracking completely, since we're seeing burndown charts that do not reflect the actual story progress.
Working more extensively with epics sounds like an interesting hint, though. I'll have to check if they are shown in Tempo, otherwise that solution would harm our time tracking efforts.
I disagree. It is actually quite helpful toward velocity, which is not a measure of short, but long term planning.
A classic example is this- suppose a team averages 85 points a game so far this season (lets say 10 games played). It is safe to say they will average 85 points over the next 5 games, but NOT safe to say they will score exactly 85 points next game. They could score 70, 100, or anything else.
Stories dragging through means they are too large for a single sprint, and should be decomposed further. Counting partial points, or re-estimating afterwards would only hide that issue, hurting the team long term.
So if your team targets 40 points each sprint, and the 8 point story is NOT completed this spting, the team only delivers 32 points. But next sprint this large story will be completed quickly, allowing the team to actually meet their 40 point commitment, AND pull another story into the sprint delivering ~48 points. The average of the two sprints is still 40, and the velocity remains true.
I have to agree with Eddie here... if you're in that situation where you're 90% done with a Story, then its not "Done Done". You roll it over to the next Sprint and finish it. Yes it will 'suck' in terms of Story points completed for the Sprint where most of the work was done, but the next Sprint will have a higher number . But over the course of several Sprints, your velocity will be accurate; it all works out in the wash.
If this happens consistently, and your burn down charts are very 'spikey' because you roll over things frequently and they also drop fast towards the ends of the Sprint (showing little progress during the Sprint), then I think you need to re-evaluate the size of your stories and make them smaller (decompose them).
Thanks for your replies! I've been trying to adjust the story size over the last couple of sprints and I think we've found a good size right now, summarizing them in epics. Works out much better so far, plus we can quickly see the epic (feature) progress in the planning board.
I would just say that it seems that for Jira proper a product goal was to be flexible enough that customers could configure their system however they felt it best fit their business.
For Jira Agile - it seems like the majority of the answers I read to concerns like the one expressed here are "You're tracking your project wrong..."
-Your stories are too big
-Your sprints are too long
-Your definition of 'done' is incorrect
-You should burn hours not story points
-I don't know why you would want to track your project that way...
We don't use Scrum, we don't use Kanban, we use the what we believe are the best parts of many strategies - that fit how WE work best - and it can vary from team to team... It seems Jira Agile is missing the flexibility that we have come to expect in other Atlassian offerings.
My personal opinion.
Hi Mike, I think that is a perfectly valid opinion, and expressed very well.
I know I've been one of those to make such statements on this thread and others, but I'm just a guy, not an Atlassian employee, so take anything I say with such importance ;)
I can completely see your frustration. Being told "your doing it wrong" is not constructive in itself. I am also sure folks who authored this, http://agilemanifesto.org/authors.html, who are often cited in such feedback were probably told they were doing it wrong at first too!
But I think the authors of the tool have a balance they need to adhere to. This is the classic 80/20 battle we deal with ourselves. Its more important to deliver something effectice for 80% of use cases, then to try to tailor a bloated solution to hit all 100.
- Feature Breadth and Richeness
These two are often at conflict, so the effort to make JIRA Agile do _all_ the things the people want means either less total features, or shallower features. To that end the authors have (wisely IMO) used the established practices of Agile (Scrum and Kanban) to limit the need for customization in order to deliver a really rich and full featured tool for 80% of their customers (again, just a customer, assuming the unversal 80/20 rule)
I know that doesn't give you a solution, but I think it lends value to the conversation of how Atlassian priorities and delivers feature requests. https://confluence.atlassian.com/display/JIRA/New+Features+Policy
Just to add to this, I suspect that the syptom you're witnessing is infrequent drops to QA.
You've got your user story and everyone will generally agree that during the development there will be distinct pieces of functionality that will be built, one step at a time. We use BDD scenario's to focus this but you don't have to.
The thing you want is for devs to push these incremental updates to QA as they go along so at the end, the QA's have only got a tiny bit to do and any bugs you've found along the way have hopefully already been fixed. If you go down this route you will generally find that the development tasks aren't complete at the end either (assuming the story isn't finished and signed off of course) because they have been fixing bugs from the early QA exposure.
Does that make sense?
The challenge is that tracking progress inside a sprint should be separate from the estimation techniques that we use to track velocity. If we are using "appropriately sized" stories that cut through all the layers needing the team to collaborate to complete, we may only pull in 4-6 stories for a 2 week sprint. If we are using the burndown to track the progress of the sprint, because this is based on Story Points burning down we may not see movement for days or even towards the very end of the sprint. The whole story not being completed until the last few days of the sprint is a perfectly healthy situation. What should be happening though, is that stories are broken down into tech tasks. These should be what is burning down. These are how we see progress throughout the sprint, not the stories themselves. The only way we can currently see movement this way is to use hours estimates on tasks, but even on these smaller tech tasks, we are still terrible at hours estimation, so a lot of coaches/scrummasters opt for either t-shirt sizing, or just using issue count. Wish we could burndown this way rather than relying on hours or full stories as it is closer to the way I have seen most teams work.
We have this same problem. We complete our stories within the sprints, but the burndown is a flat-then-cliff shape more often than not. We don't want to go down the route of time estimates for tasks as this rapidly devolves into unhelpful discussions. Being able to track the story points of sub-tasks would make the burndown chart a meaningful tool rather than a pointless add-on. As it is we all look at the active sprint board and squint and imagine what it'd look like if it was a graph.
I have a flavor of this same challenge; however, I really don't want to use subtasks. We have a suite of applications and to implement a user story work is often required in multiple applications that interact with each other. In order to not miss anything we first tried using subtasks under the parent user story to ensure all tech tasks are accomplished. We also discussed any dependencies between subtasks in the daily stand up to make sure the team is on the same page. This, as many have noted, creates a progress tracking challenge unless the user story's story points are manually decremented. The other problem I have with this is I really want to have an independent JIRA project for each application so I can utilize version numbers and components, as well as tweak workflows if for some reason one application had a slightly different workflow for development. It also will allow me to have QA independently test the applications or I can choose to have QA test a "package" of applications by modifying the JQL used to show a "release" on the Kanban board. I am not sure if there is an ideal way to run a hybrid scrum/kanban board (scrum board used to track development and kanban board use to track testing a release and completing all the end-user documentation for that release) where the tech tasks are actually tickets within each respective application's JIRA project and the user story lives in a "parent" JIRA project. I know I could go the route of creating a separate user story per application but that feels wrong. In an ideal world I could have a parent JIRA project where user stories are created, decomposed, and backlog groomed. Once the user stories have sufficient info to begin development I would create, with the assistance of development, the tech task tickets in each respective applications' JIRA project, then somehow link them with the user story, and of course place them in the upcoming sprint. This approach isn't ideal because linking the tech tickets in the application JIRA projects to the user story in the "parent" ticket is "hidden" when viewing the backlog or active sprint. The only idea I had was that once the user story can be developed it's converted to an Epic and then the tech tasks can be associated with the Epic for quick viewing on the baclog/active sprint. Any thoughts/suggestions?
I feel like I get this answer from Atlassian very often: "Well, it can't work that way, but that's not the right way anyways so we won't do anything about it"...when in reality Agile promotes figuring out what is right for you.
For example, this.
Saying that "it is ok for stories to burn down all at the end of a sprint" makes no sense. Why use burndown then at all? I use burndowns to see if we are on track to finish on time and in full, so if I see a burndown that just stay steady unil the last few days and has one big drop, but the team agrees this is ok, then it is of no value. The way we get around this is to track more granularly, at the sub-task level, but I am told "nope, that's wrong practice...go back to what doesn't actually work for you, because we won't fix that".
I've read all of the above, and I don't want to sound like a broken record, but story points on sub tasks would be a brilliant way forward. We have a massive project existing in JIRA, and we can't easily move everything to epics, and then use stories as sub tasks. We need to see how sub tasks are closing out during a sprint, and at the moment, we are manually decreasing these from the story's story points, in hopes of getting a burn down chart. I think the best way to set it up would be to give the user the option to put story points on either the story, or the sub tasks. If the sub tasks were chosen, then the story would have a sum of the story points on it. And as sub tasks were closed down, the burn down would show it nicely. I think a lot of us are asking for this. We can do it if we work together! Thanks
Yes. This would be perfect and seems to be exactly what hundreds of JIRA customers have asked for over the years. I really don't see any good workaround for Scrum teams that estimate Sub-tasks using Story Points. It seems like JIRA is set up for Scrum teams that don't use Sub-tasks or use them in very different ways than I have used them in my teams.
I have exactly the same problem whereby I want to have Issues that can span across multiple sprints but have sub-tasks completed within the sprint and have story points allocated to sub-tasks. Story points for completed sub-tasks within the sprint should be credited in that sprint. The main problem with switching to using epics as the parent issue is that epics don't appear in the product backlog and this doesn't suit the way our team implements agile. Atlassian can we make the product more flexible to allow sub-tasks to be effectively another hierarchy level down that are sprint tasks in their own right.
Hi Guys, I agree with the above. Though a story is not complete until all sub-task are done, it is useful to see how the team is tracking throughout the sprint in regards to meeting their goals. This is how I worked around the issue with sub-tasks previously: First of all, use 'tasks' rather than sub-tasks, then link these tasks to the story. For each of the tasks, you can then assign burndown points. To do this, change the estimation settings to burndown points, then edit each task and assign the points. E.g. if a story has 8 story points and you have 8 tasks you could simply add 1 burndown point to each task. The above should be done for all tasks related to that sprint and prior to starting the spring. Then when you start the sprint, you can track the progress through the sprint report (ensure to select burndown points for your estimations). It's a cubersome solution as tasks don't link to a story as nicely as sub-tasks though it does get you a more meaningful burndown graph.
You're really missing the point if you're sizing sub-task. I can safely assume that you're trying to work in an Agile way as you're talking about Scrum teams, but you're Scrum Master should be really heavily advising against sizing sub-tasks and coaching the team as to why that is not the right thing to do.
Sub-tasks are just a way of documenting things that need to happen in order to complete a story and deliver the value within it. The sub-tasks should offer no value on their own, therefore they don't get points - points are exclusively reserved for backlog items that deliver value to your customers or stakeholders.
If you're finding that your sub-tasks are valuable on their own then your stories aren't broken down small enough, that'd be my guess.
I disagree with the previous comment. In some software environments stories can not be accomplished in a few weeks, and therefore can not be seen as accomplished entirely within a single sprint. However some milestones may have well been reached and sub-tasks completed within a sprint. It would definitely help to have the ability to switch on sub-task accounting in the burn-down charts. Since it's possible to have story points at the level of sub-tasks, it seems a bit of a "buggy" situation that these are then not taken into account in the burn-down.
Story points on sub-tasks are needed to:
Stories are sized based on what is valuable to the user. In our organization, a story frequently does not fit inside a sprint; especially when the definition of done includes manual QA, UX QA, and automated QA.
I also find that story pointing is much more accurate when done at the sub-task level.
Resource capacity planning is also much more accurate at the sub-task level. A story can be 3 points for feature engineering, but 8 points for automated QA.
We use epics to group stories that support a small-medium tactical or strategic "initiative".
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot