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".
Rolling over stories to the next sprint is not Agile Scrum. It means your sprint failed. It means your stories are sized incorrectly. Allowing story points on sub-tasks for most of the reasons stated here is simply a workaround to mitigate poor Agile practices, probably because you don't want to actually implement Agile Scrum.
Your stories track features, but most people are thinking of features too broadly. Broad features are tracked with epics, and broken down into discrete pieces to be implemented, which are tracked in stories.
A 2-week sprint should favor 1–3-point stories, with 5-point stories being used very sparingly. Otherwise, QA will get bottlenecked during the middle and end of the sprint.
I don't understand why this is such a black and white issue. So the users care about individual stories. Development teams care about progress to complete those stories.
Why not just have some way of tracking story progress? It seems like the suggestion is to put the onus on making the customer think about breaking down their stories.
eg. a story represents something that meets delivery requirements. The work that needs to be done to meet those delivery requirements will take more than 1 sprint. The customer doesn't care if that work is done before the end of the sprint, takes 2 sprints, if it's really an epic, etc etc.. Breaking down a large story into smaller chunks seems like a good idea.
The problem is, just because we as developers can break this down into smaller chunks doesn't automatically mean that any of those particular chunks is deliverable in any useful sense to the customer. What't the customer going to do with the sign sealed and delivered API if the UI is still in testing?
The API is not the story. The completed feature is which requires development in several areas of expertise. Database, UI, API, Business Rules, QA, Integration etc etc.
In my mind, those are all sub tasks of the story. Those should rightly be track-able independently of the story. If we assign 12 points to the story we should be able to break that story into the task of each of the areas of expertise without having to call each of those tasks a "story", and without imagining that when one of those tasks are completed, signed sealed and delivered that it will represent some benefit to the customer in it;s own right.
The software should be flexible enough to consider this probably extremely common use case and users should not have to figure out workarounds to materialize this end goal.
I am here because I search for, "how to allocate story points to sub-tasks". I am in the same boat as people have been 4-5 years ago in this thread. My burndown chart looks more like a collapsing pancake rather than a curve because the issue is so black and white. It seems like I would have a nicer looking chart if there were to be some grey area.
I'll probably just use log time and ignore the concept of hours in the labeling and consider the number I put there to be the allocation of story points for that tasks back to the story.
And after a quick glance, that is exactly what I see beneficial to do. Use "time tracking" because it breaks down those stories exactly how I imagine it should.
The sad and tragic part is, I have to enter time as something like "4h" instead of just 4. So I can just pretty much ignore that, but the truly beneficial piece of this is that fact that the tasks role up to the total in the main story.
Such a relief to know that the functionality is indeed possible. I can even switch my charts to use those numbers (hopefully instead of the story points). Hopefully it won't show 24h as 2 days and just leave it as total hours. 0_o weird work arounds to make the software act how I would intuition.
You don't have to use time tracking -- you can just use subtask count and still get the burndown to indicate what you need. It's not about hours, it's about progress - a proper burndown shows progress and allows for near immediate dynamic change - it's an indicator, not a reporting tool.
Still -- Jira can't do this either. Scriptrunner can however - it can count subtasks under issues in the sprint, and burn down by subtask completion.
Hours are completely arbitrary - as hours do not equal effort, but you can still get the metrics you need, which really is an indicator of the "health" of the sprint - by burning down by number of subtasks. This assumes that you never have a subtask that is more effort than "1 day" of work.
Thanks for the tip about "scriptrunner". I understand that it's not about hours. My idea was trying to use the system as is to achieve the point of burning down subtasks in some coherent way that aligns with what I expect to see on a chart. Even your solution sounds like it doesn't have the flexibility of getting rid of the "clock" constraint.
All of the functionality is there to handle this by using hours/minutes/seconds etc... just the labeling is not right. It's easy to ignore the h for hours and d for days. It's just too bad that I might have an epic that can broken down into tasks that can be broken down into sub tasks and when it roles up 24 points becomes 1 point. OH WELL.... No way to fix that. Or is there. I want the functionality of breaking down projects by subtasks and time charting to be used in story points. Too hard to do I guess?
FYI - VisualStudio does this if you want it to. shows velocity in story points - which gives you a timing estimate, and burns down sprints by subtask. It also does NOT roll up sub task estimates into the user story but I *think* it will roll user story up into features and epics (their heirarchy is very SAFe - capabilities --> epic --> features --> stories --> subtasks.)
rambling a bit more on this whole thing....
So really there are sort of 2 things at work here. there's the "reporting" element, and the "Progress" element. For example, the reporting element doesn't really help the team on a "day to day" perspective, but it helps the project management and powers that be make "business" decisions. I would say that the burndown when used by the team is about progress, not reporting. Jira is bad at this as it was built from the beginning to be an hour based system - it was a bug tracker.
If you think about it - there is a constraint as we measure forward movement as "time". And what you are looking at is how much work is forecasted to be done vs. will most likely be done in "x" period of time. You just never know the ratio of work to time. What you do know, is the "to do" list for each of the stories. that to do list, is the sub tasks under the story.
so you have epic, broken into stories and you achieve those stories through each of their "to do" list - i.e. sub tasks.
If you think about everyone's day, we have stories and subtasks all over the place in our lives. This weekend you have to paint the garage door. the subtasks for that (i.e. your to do list) could be "get paint" "get brushes" "find drop-cloth" "make sure you inform family of when work is happening" - You have till the end of the weekend to get this done. You check things off your to do list, and you use those to dos to mark your progress (along with visual inspection). The end goal is clear, and the end goal could be part of a bigger project vision (I.E. "fix up garage") AKA Epic. (By the way, I do know several people who use scrum in their personal lives like this)
What I'm saying in all this is that Points at an epic or story level really don't roll up from sub tasks. I argue that estimating on sub tasks is only useful for 1 thing - and that's having multiple developers discuss them. if one developer thinks something will take all day, and another thinks it will take only their morning -- there's a discrepancy there that is revealed by their estimation, the actual number is not important - the fact that the number revealed a discrepancy is what is key. single developer teams or high functioning teams - don't need sub task estimations, but they do need burndowns based on number of subtasks in the sprint - i.e. how far along are they on their to do list.
Story points on the other hand - those give velocity - a relative value specific to that team and that team alone (it's tough to get multiple teams to align on what a "5" is - it can be done, but it's difficult) Velocity numbers are your single data points that make up the points of the project burndown. Velocity every 2 weeks is a 10 (and it has been for 3 sprints or so), and there are 60 points in the backog - right now, based on what we know, we'll be through the current backlog in about 12 weeks.
How long did it take you to paint the garage door? about 1 weekend. Did you determine that by adding up your to do list? of course not! (subtask level). based on how long it took to paint the garage door, how long will it take before the garage is fixed up? (story point level)
The fact that there are 2 different things with different reasons at work here each using "time" in a different way seems to be a point of conflict in Jira.
Ryan, thank you for your thoughts on the matter. I've gained a new perspective on sub-tasking thanks to what you have said here.
My perspective is layers. When a project starts, it is not often know what the demarcation is between these layers. We know that a project is the top layer and everything emanates from a project. These management systems give us several additional layers to work with. Epic, Story, Sub-task. The lowest layer in those systems become the unit of effort. I am not sure how anyone would see a layer below the effort layer. It's like splitting atoms I guess.
The lowest layer in my mind is layer where effort goes. In your analogy of planning to paint the garage door, you must know key details about how much effort it will take for each of these things to happen. For instance, do you need to drive to the store or do you already have the supplies? If you do need to drive to the store, can you combine some effort to save time in picking up drop cloth from the same store as paint brushes. If one of your sub tasks is blocking, will you need to also pick up light so you can paint at night?
These are the things effort is based on in my mind. Now, you may have painted a garage enough times to know you can do it in one weekend, and that is fine. You give effort based on the next layer, and you don't consider the effort it takes to do each piece in detail. However there are many development projects that software engineers take on that look nothing like anything that anyone has ever done before. It is helpful to have several layers of granularity in the effort process that role up to a story or an epic.
In this way, I feel that resources in these projects are better utilized as the project matures and more details come into view. This allows a software team manager to not have to worry so much about getting the project structure right which ends up informing architecture decisions once a project gets so far along that managing the project tool becomes a pain point.
First I'd like to say - I've really enjoyed this back and forth, thank you for having it with me!
and now my rambling continues....
What goes into subtasks is an unknown - but you, at the time, THINK you know what the subtask is to move you forward. no one "knows". that's impossible. Jeff Sutherland (one of the "inventors" of scrum) mentioned that in all his days he only saw 1 company EVER do upfront planning and have it match what was produced (Bell Labs, who are long since gone). The reality is what we think of as "science" is really more "art". there is immense creativity in software creation - NOT! just in the manifestation of said software. Unlike painting a garage, software is NEVER that concise in how to move forward - it's creative (It's more like "uh, what's a "garage" and why does it have a door?). We need to move away from treating software creation as factual, and recognize the creativity required - nothing is certain. Since nothing is certain, there is a point where you have to allow uncertainty in and simply plan to mitigate it. Things like Worst Case Scenario drills and Failure Analysis will show - nothing is ever, at that granular level as bad as it can be made out to be. Big "A" Architects also need to realize that upfront doesn't work - what does work, is treating architecture just like you treat healthcare compliance - make it part of acceptance criteria so every single thing done, adheres to that "standard".
I would contend that by trying to control things at that minute day-to-day level, you end up stripping out all the great things that can be contributed by some VERY smart people. The idea that the people that do the work don't understand the work is lunacy, as this isn't make-work job shop stuff - this is professional and creative (and one would think that Developer pay scales would indicate this, but for some reason - their payment has never been linked to their abilities beyond simply writing code).
You say it well when you talk about things that don't look like anything else before -- I would say, if you give members of a team the picture and let them in on what is trying to be created and what the end goal is you'll give those people more purpose to their work (and in turn, they'll work "better") and you may find a whole new solution to the problem - one that others never even considered. I've found that developers when given real access to the business problems and given good information, can come up with solutions that far outweigh the pre-conceived business ones AND often they're more cost-effective and more efficient. You know where Atlassian came up with some of their products? they gave all the developers 1 day off a week to work on anything they wanted to for the company unstructured! They removed control and allowed smart people to be smart. Now, one could argue that this was quickly locked down, and in turn we get the mess that we are discussing right now, but that's a whole other story.
I think things don't get done "right" *because* of the layers - I don't think the layers help, I think they hinder. Now, organizationally I get why they are there but my main goal always is to shorten the path between users and the team building things for said users as much as possible. All those companies out there that we all want to be like -- this is what they did. they shortened the delivery path. This is scary and it flies in the face of PMP and PMBOK and ISO and all the other letters of the alphabet. But it's how you build better software. A great Product Owner does everything they can to involve the team. Neal Whitten, a legendary Project Manager said a great project manager is a "Benevolent Dictator" - I would argue that great project managers, truly great ones were really Product Owners in disguise. Someone has to make a decision, but that doesn't mean that others aren't heard and considered. I involve my team in everything they want to be involved with, and I always hear, at every client "that's not efficient", "that's not necessary", "they don't understand" - and then we out produce every team they have. efficiencies are about smarter, not longer or harder. that loss of "hours" is made up with through better understanding every single time. At first however, developers are terrified of this. they've never been allowed to be "free". Once they get past this, and ideas flow - it's amazing what they come up with. They're smarter than me! and then you have...7 of them of them etc in a room, working on a problem, whiteboarding a visual solution for UX, etc? it's arrogant to think that 1 person is smarter than that.
Try removing some of the links in the chain, shortening the delivery path - you'll see some amazing things happen. Now, how do you get the various higher-ups to go along with it....that's a tough one, when it is tolerated by the business - what sells it is the results it achieves. It's amazing what happens when you let people be smart - and the best thing to do is to sit back, and collect the rewards that ensue.
Nice read !
In short: there are a lot of people that would use story point estimation on subtask level to suit the needs of their team(s). And there are a lot of people that would not use it.
In my opinion this should be an option in JIRA. And it would not even be that complicated when it is based on the existing time tracking functionality.
For my team, we use subtasks for the visual representation on the active sprint board.
So the implementation of a story in the iOS app, Android app and web app are nicely grouped together. Normally a few of these stories will be implemented in 1 sprint on all platforms (as the client wishes to keep it consistent). So subtasks are, in the end, stories with their own value (we could push the android app with the new story, without pushing it for web for example)
Now I could add up the story point estimates and put that as points for the parent story, but that leaves me with little information later on. The web task might be estimated at 1 point and the iOS task might be a 2 or a 3. This is useful information for 2 reasons:
1. Velocity for a single tech stack is useful to spread the story points over the different tech stacks correctly in subsequent sprints. (wont make sense to put all 25 story points on iOS and none on android and web when the team velocity as a whole is 25)
2. When the story is not implemented on all platforms for whatever reason and it moves to the next sprint, it is not clear how many points remain.
So regardless on how story point usage is intended in JIRA, my team has a wish on how it wants to use it and I have nothing against it from a Scrum perspective.
I think I will have a look at using the time estimate (in weeks probably)
be careful that you aren't assuming that stories are the same effort accross platforms - it's been my experience that is not the case. i.e. "log in" iOS might be "5" but "log in" Android might be "8".
velocity is velocity, regardless of what platform the team is working on - a sprint that is a "21" is a 21 regardless of what was in the sprint - it's why relative value that is consistent is useful. If you think about it, it can't ever be wrong - the only way it can be wrong is if it becomes inconsistant in it's relativity. i.e. the same effort for something that would have been a "3" is now for some reason, a "8", that's how velocity becomes inaccurate. The attempt to tweak numbers is what can mess up velocity. People's attempt to become "more accurate" is honestly what makes velocity less accurate!
The efficiency concern I would have regarding working multiple platforms in the same sprint is around context switching, which can be very costly and is often ignored. Developing is hard, and to switch a team's entire platform for 1 or 2 stories - that can be very inefficient.
I use a very simple system, and it's what I teach and what has been most successful - user stories in points, subtasks with a newer team in hours (only 2, 4, 8). Once teams are high functioning, you can just give all the subtasks the same effort (1) and burndown on subtask count vs sum. remember, subtask 2,4,8 are really just a representation of morning/half day/full day, and are there so that discrepancies can be revealed.
This also separates the scrum ceremonies - i.e. refinement is points, planning is hours. one is about forecasting, the other is about getting work done.
I don't ever report out on hours or ever tell someone we have "x" hours of work left in the sprint. that's a bad direction, and allows people to start to micro manage teams. subtasks burndown daily (reveals impediments quickly), user stories are done/not done via iteration (sprint), Backlog burns down on user stories (i.e. velocity)
This is actually very simple regardless of their being "two estimation systems" (as I saw someone mention in a thread about this). There really isn't two systems though. the only thing that is an actual estimate is velocity. everything else is a to do list to get things done and is for the team. The business NEEDS "estimate", the team likes to see estimate but needs to do lists and business problems to solve and ways to work better on a daily basis. Treat these differently, because they have different reasons to exist, and different ways they help their intended audience.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
...PermissionsStartOnly=true User=www-data Group=www-data ExecStart=/opt/jira/bin/startup.sh ExecStop=/opt/jira/bin/shutdown.sh TimeoutStartSec=120 TimeoutStopSec=600 PrivateTmp=true [Install] WantedBy...
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