Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have the following question.
Often in our project issues stay in progress forever.
To resolve this we would like to introduce a new workflow where if a JIRA issue has been idle for 2 weeks it will automatically have its status set to Postponed.
How can this be implemented in JIRA? I checked the column constraints on the board, but there is no constraint related to time.
I think you don't have to build a workflow to mask your problem with regards to the "Issues which stay in progress forever", but you need to fix it.
Fixing it means you need to coach the team and support them with various technics to avoid "never ending stories". I would suggest to:
Implement DOR (Definition of Ready) - avoid picking up issues which are not yet investigated, groomed and not enough clear to pick up. In our case the story could be added into the sprint just after all external dependencies are sorted out. Use the INVEST model which says INDEPENDENT How can you commit to deliver issues where you depend on any external team?
Slice big stories - There are plenty of technics how to split large user stories. In general its a bad practice to add a story into the sprint if the estimate shows that it can't be completed. Ideally the right size of the story is "that you have 2,5 story to each dev in single sprint". This doesn't mean that every dev should work on his own story and they can't collaborate, but it means that for e.g. 4 devs for a single sprint 8-10 stories are ideal. (Easier testing, collaboration, better planning, more stable velocity, etc etc..)
WIP (Kanban limit work in progress) - Putting the 'flow' back in workflow with WIP limits - Atlassian This is something which is easily configurable in Jira.
Show the 'DAYS IN COLUMN' indicator on cards - This shows a series of dots on each card (up to the width of the card or a maximum of 32), representing the number of days that the issue has been in the column. This could be a useful info for the scrum master to see whether there is any impediment which should be sorted out
Don't use blocked or postponed status. This is just my personal advice. Statuses like blocked/postponed could generate a habit that the issues will be really just postponed instead of removing the impediment and blocker. It is always easier to flag something as blocked as removing the impediment. Its your scrum masters responsibility to remove the obstacles and eliminate the waste.
Backlog grooming - Groom the backlog periodically and if you have problems with the external dependencies flag them in advance. Seek for external dependencies by purpose and identify them as soon as possible. This will give the SM/PO hopefully enough time to deal with them before the issue will be added into the sprint and picked up by the dev team.
Why an issue is sitting idle for two weeks? Is it because of external dependencies or issue is too big to complete in two weeks?
I am not sure about the Jira work flow and if Jira can move it to postponed state. But you can move it back to backlog at the end of the sprint.
But if it happens because the issue is too large to fit in two weeks, then I would recommend to slice it into smaller tasks to fit in sprint.
I hope it helps.
If we ignore the arguments how good a workflow and its management is raised by #shippi the solution to this question is explained here.
https://community.atlassian.com/t5/Marketplace-Apps-questions/ScriptRunner-how-to-change-status-of-an-Issue/qaq-p/628842
Shortly said Jira has ability to execute scripts , they can also be scheduled and executed on regular basis. What needs to be done is a script to be written and scheduled that every day checks how long an issue has been idle and set the appropriate status.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am some way through a project, on the 3rd sprint, which is about back-end processing. Let;s say the sprint name is "3. Data merging and form generation". I have 4 or 5 features in that sprint relate directly to that task, and I'm halfway though- some completed, some not, one in progress.
While in this sprint, I demonstrated some of what was happening to the client, who promptly (kind of unexpectedly) gave me a few pages of feedback purely to do with the UI. Very front-endy stuff, nothing to do with my current sprint, but still relevant and good stuff.
It seemed that at that time, it would be appropriate to drop my current back-end work and address the feedback. The reason being by addressing the UI issues, it would stop propagation of 'wrongness' to the rest of the application (Lotus Domino: That's how it works).
JIRA doens't have a facility for putting Sprints on hold, and starting a new one. You have to close a sprint.
Adding a feature to my current sprint would be fine, but would include a load of UI issues in a sprint names explicitly to do with the back-end processing.
It felt like square-peg-round-hole, and I'm not sure how this is 'supposed to' go with Agile, or JIRA.
So my question is: Is the problem that ..
Naming of Sprints shouldn't include too much commitment to their nature, so including a UI task with a sprint intended for the back-end processing woudn't be upsetting things.
If a sprint is "interrupted" like this, my notion of putting it on hold and sidetracking to another sprint isn't how Agile works (hence JIRA won't let you). Something else should happen (if so, what?)
JIRA is less flexible than Agile demands (seems very unlikely!)
Some other thing I haven't thought of.
The typical approach to scope changes mid-sprint is as follows:
If a change is relatively minor and both the team and the Product Owner agree then you go ahead make it. Typically a team will compensate for any changes, for example when they bring in a new story they would also take out a similarly sized story so that the net effect on the sprint is close to zero.
If the changes are significant the Product Owner may terminate the sprint. The team immediately starts planning for a new sprint in the same manner as usual.
It isn't all that common to name sprints with details of what the sprint contains. Just using a simple numerical sprint name (e.g. sprint 1, sprint 2) can help to make it clear the Scrum team is open to change.
In JIRA, if a sprint was terminated early I would mark it as complete and then create a new sprint. This may mess with your velocity calculation a little, but should be easy enough to compensate for.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am trying to get my head around how story points are assigned to sub tasks and how the story points are managed in Jira.
I have a user story which we have estimated at 25 points.
A developer will take this user story and split it up in to a number of tasks.
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points? And if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Also, if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
Let's pretend Jira isn't the issue for a moment.
First, tasks should be estimated in hours, not points.
Second, stories should only be counted toward the burn down when they're complete. (https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/)
Third, consider what value you are getting from the tasks. In teams where we have done tasks, I've found the work of creating the tasks a great validator of whether or not the story has been defined well enough. Marking off the tasks has been of less use to my teams.
Fourth, when a story is not complete at the end of the sprint, it should go back into the backlog for the product manager to re-prioritize. It may be that it's no longer a priority (especially if it's taking much longer than expected).
https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint
From teh scrum guide - "All incomplete
Product Backlog Items are re-estimated and put back on the Product Backlog."
Personally, I don't like to re-estimate because then some effort is "lost". If you don't re-estimate, then your velocity balances out over time, even if each individual sprint velocity bounces up an down.
In some cases, when stories tend to be large, when they are estimated to take more than 4 or 5 days you can easily lose track of progress within a sprint. This is especially true if the sprint is 2 weeks long.
Teams I've worked with have moved away from tasks in favor of smaller stories. (Currently, we use a rule that if it's > 13 story points, it's probably too big and should be split up).
All this considered, Jira should fall in line fairly well.
I find sub-tasks to be the hardest feature to use in conjunction with agile in JIRA. It always ends up being one of two scenarios, reminding why I try to never use sub-tasks to begin with:
Each sub-task is actually a story, and the initial story was way too broad. Every time I'm in this situation, the original story goes over 1 sprint, if not many sprints (causing the developer to rush, shirk, be stressed, etc)
Or, the sub-tasks themselves are too detailed and aren't worth putting in JIRA as their own issues; instead you should just add a comment to describe progress or ruminations to the original issue/story and avoid the JIRA overhead.
EDIT: In response to #DaveHillier
I don't like creating subtasks because it's more JIRA pushups. I think the allure of subtasks is that it makes your use of JIRA appear more structured, but I think an important part of using JIRA well is to keep issue count as low as you can, and yet still be effective for the team. I can't possibly justify this why I think issue count should be low in this thread, other than to say, ' with JIRA, less is more'.
Let me show you what I do that satisfies the following requirements:
transparent progression on the issue (other users can be notified if they want)
lets me organize my own thoughts
remains inline with the issue, letting someone look at my one story and understand quickly where I'm at
I make a list in the description of my main story, using JIRA markup like so:
Build the thing. Lots of words blah blah.
h3. Progress
* code it
* test it
* deploy it
Then using JIRA markup, I can add little green checkmarks as I get done using (/) next to each bullet point, letting any 'listeners' of the bug stay abreast of my progress.
Build the thing. Lots of words blah blah.
h3. Progress
* (/) code it
* (/) test it
* deploy it
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points?
No, tasks of a story are not assigned any points because one completed task will not provide much value to the client / enduser. All the tasks combined will deliver a working piece of code much would be of some value for the enduser. In essence a story is not complete till all of its tasks are done. Remember: Working software is the primary measure of progress.
if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Since task dont have any points (as mentioned above), this becomes obsolete.
if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
If a story remain incomplete at the end of the sprint then you have two options, either move the whole story back to the product backlog or if any part of the incomplete story can be salvaged and treated as a working piece of software then split the story into two. Working part will be considered complete in the current sprint and non-working part will become part of the product backlog. This part will be treated as a new story and it should be estimated as a separate story. You cannot split story points between the working part and non-working part.
Sub tasks don't work well in with Jira Agile.
In my current team we don't use them.
I disagree with sethcall, that there are no reasons that I should be using sub tasks.
I'd like to track that I can't easily at the moment:
tasks for completing each point of a definition of done
tasks to make acceptance tests pass
There are plugins that support acceptance testing, (e.g. Behave for JIRA) however I have no experience of them.
Some have suggested to use custom fields for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list.
Here is an article that suggests using checklists for acceptance tests.
Might be worth a try.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have bought Jira, Greenhopper and Confluence and I have been using their products, but I have not been very good at writing tasks properly.
Let say you have a task in your project that you know consist of several minor tasks, then you would make subtasks to the overall task. What happens when you have completed all the subtasks? Do you drag the overall task over as well (I mean the parent task)?
How do you write your tasks? Do you write them just like: "Create Customer table in database"? And if this task consist of making indexes, constraints etc do you write subtasks to it? Or do you write tasks in another way?
As all things management there is no common practice in this, but here are some guidelines I personally use and we integrate in our company.
The summary should be descriptive of the issue. It should not contain a word describing an issue type: bug, feature, task etc. That's what the "issue type" attribute is for. For example: "Re-check the site for any problems, resolve permissions issue" or "Text corrections".
It is good to have the Priority, Due Date, Environment, Component/s, Affects Vers, Fix Vers and Labels attributes - for those that you're using but keep in mind that the more attributes defined the more information an issue holds, the more descriptive it is and the more manageable.
The description field should hold all available information described in a formal manner.
Sub-tasking:
This solely depends on your organization, but there was a bug in Greenhopper that I personally reported and is now resolved:
"Sub-tasks' estimate does not show in Master Task in RapidBoard's Plan Perspective"
"We are experiencing a problem with rapid board sprints.
Our Master issue * does not have an estimation of its own, but does have an estimation when you include the subtasks.
As you can see from the attached screenshots, when we include this master issue in the next sprint, we do not see the estimation sum for all of its child issues.
They are not shown at all."
So for subtasking we now use this new (fixed) feature - the master tasks's estimate is the sum of all estimates for an issue. I personally subtask only when the master is something very complex, but with my job that's every day's work.
Hope this helps but again this is my personal opinion.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are in the process of starting to use Scrum (in combination with TFS 2010 and the MS Scrum template) in our company. Since none of us have any experience there are still some questions to be answered.
Since our Product Manager and Scrum Master are non-technical people it would mean that we, the Developers will be part of the meetings that split up the feature requests in small Product Backlog Items. It is my belief that we can do this on our "planning poker" meetings to discuss the feature. But how is this planned in? Let's say that we get a new feature request in the middle of our sprint. (Our sprint will be 80/20 timed.) Should we keep this also into account when planning our sprint, or would it simply mean that the time we spend in that meeting must result in items moved back onto the Product Backlog.
We know we should split a feature up into as many PBIs as we can (and of course, that makes sense) and that a single PBI should not exceed the length of one sprint. That also makes sense. But where should we draw the line? For example, our application communicates with several USB devices. The feature request is that we should communicate with a new device. Implementing this is a 2 part job:
a) add the communication with the device to our USB library;
b) add UI support for this device
Should we split this up into two separate PBIs, or is this one PBI of which we should create multiple tasks?
On a side-note: when a PBI has been added, should we create a task for each PBI when we start implementing it? As far as I see in TFS we cannot set remaining work hours on a PBI. So my initial idea was to create a task for each PBI. But I know some colleagues will find it "a lot of work" to create a task for a PBI that only has one task. How should we handle this?
In Scrum, it is the PO's responsibility to break the features into small-enough user stories. That being said, there's nothing wrong with the PO getting help from the team (or anyone else for that matter) in splitting them. The planning poker session might be a good place to fine-tune the split, due to the team's input on the complexity of each story, but the PO should have a sense of how to split the stories beforehand.
The planning session should take roughly half a day. Definitely not a significant portion of each sprint. Regardless though, the remaining hours in the sprint (e.g. 90-5=85, in a two week sprint) should be the amount of time that the team has to fill with the stories' tasks. Of course, no matter how much time is left in the sprint, any stories that the team can't commit to should be returned to the product backlog; they won't be done in this sprint.
The stories should be sized appropriately, i.e. can be completed in a single sprint. Personally, I prefer to size stories so that a few stories can be completed by the team in one sprint. A good rule of thumb (but not a hard rule, by any means) is to stop splitting your stories when you reach the point that they can be released by the team in 3-5 days.
Though you didn't ask how to split your features and split them along the lines of Core capability, entry barriers, key differentiators, and nice-to-haves.
Regarding Breaking the stories into tasks: You should have at least one task per story. Stories define what needs to be done; Tasks define how. You should probably have at least one task per participating component of the system, as well as one task per actionable item in your definition of **done. If you have only one task, then you probably don't have a definition of done, or your stories are defining implementation, rather than functionality.
With regard to TFS - TFS doesn't change any of the above, though it does support everything I suggested.
Yes, it's better if you create tasks under PBI even if its only one task, because the PBI was made to monitor product progress, it used story points in estimation (Relative Size), but the task is used to monitor work progress, it used hours in estimation, so every work items have different purpose.
1) The time taken to split the stories out will be reflected in your team's velocity so you shouldn't really have to do anything to plan it in. If you are spending say, half of your sprint in story planning/splitting and getting 5 stories done per iteration, then your plans will reflect that. Through the use of retrospectives you can see that spending less time in story splitting will increase your velocity to say, 8 stories per iteration. Keep an eye out for side effects of spending less time splitting stories though so you can see both sides of the coin.
2) Not knowing the application, I would say that one way of splitting this out would be
Alert User When New USB Device Is Inserted (This would show potentially a default icon)
Alert User When iPhone is attached (This has more specifics around the device, and potentially a different icon/image)
Alert User When Android is attached (Ditto above)
Alert User... (Potentially one for each of the supported devices)
Definitely try to avoid splitting across technical lines such as "Front end" and "Back End". It feels right at first due to our technical nature, but demos don't really have the same impact and your PO and Scrum Master won't really have as good of a measure of progress.
3) Task creation is something that your team needs to figure out. If you're running 2 week iterations and the team is not finding task breakdown useful, then I'd say don't do it. If the team feels as if it helps them break down the work necessary to create the story then, by all means, do it. Task creation for the sake of task creation doesn't make a whole lot of sense IMO.
Hope that helps!
Brandon
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There are several ways to do burn down charts in Scrum.
Some people suggest using the story points of unfinished stories left as your burn down charts in Scrum.
Pro: Only finished stories lower the chart
Contra: Chart doesn't move down in the beginning and then rapidly falls off
Others suggest to use the number of tasks left
Pro: Chart will move down, you can see if it is above the finishing line
Contra: You could move down to say 10 tasks left (hard tasks) in the end, and still have not one story finished. You've failed because only finished strories are good for your product owner.
Is the solution to have both a points-of-not-finished-stories and a not-finished-task chart?
We are using remainig time for sprint burndown - teams can see progress every day. If there are flat parts, than they really occured.
In the release burndown we are using story points. Release planning is more about he feature completness, the time is tracked on the sprint level. Product owner is interested in completed stories.
Number of tasks is useless. This number can be changed every day, especially if you give a "freedom" to developers. They can split the task to smaller part without the change of the total time. Such statistic is useless. What is it indicating? Does it affect the goal of the sprint?
In my opinion, tracking tasks is a rather suboptimal approach to tracking. In my experience, a story seldom really is the sum of its tasks - and often, while implementing a story, I find that the task breakdown was suboptimal, anyway.
And, while I find value in brainstorming tasks while estimating a story, I prefer to have stories that are small enough that there is no urge to track them at all. In fact, getting credit for tasks finished is highly misleading, as having even half of all identified tasks finished still isn't any guarantee that the Sprint will deliver any value at all. And that's what the stakeholders are interested in in the end: how much of the projected value will be actually delivered?
So, tracking stories and working on further breaking down stories both gives more accurate feedback and reduces the risk of no value delivery.
Actually, when working with small stories, I don't see much value in Sprint burn down charts at all - just watching stories on the wall of cards move from "to do" to "in progress" to "done" should give you all the information you need. A Release burn down, though, that can be quite valuable, in my experience.
We usually need to track hours (estimate vs actual vs estimate to complete) against stories for the clients who asked for them. This allows us to do a few things:
Track progress for that client's needs so their project manager has some insight into what is happening.
Review estimates against actual work required in order to improve our estimating ability.
Bill clients for time actually spent in case it is part of an hourly rate job.
Give developers feedback about their progress so they can manage distractions appropriately.
We also track completed stories for our own burndown, but as has been pointed out this can lead to a plateau effect at the start of the sprint that serves to tell us very little useful info (other than that we're not doing enough in parallel).
Burndowns (or even "burn ups") should only indicate work remaining.
If you've half done a story you can't ship it, and it doesn't count. If you end the spring with a story half-done - tasks that were done in it don't count if you're measuring velocity.
Just chart stories left to be completed.
This is a tougher measure but there's no use massaging the figures - scrum is supposed to communicate bad news so that things will get fixed.
We do both, as if we didn't include tasks our line would plateau in a way that makes it look like nothing is getting done.
If a story takes 2 days to finish, then you have a flat line for 2 days, and there's no way to tell whether the team is sitting on their thumbs, or that work increased (thus a jump in task hours).
Of course the task line can plummet without contributing to finishing stories, which is an anti-pattern that can occur if developers can choose tasks at will.
Tracking the number of remaining tasks is not very helpful as the tasks are likely to have different sizes.
You should not find yourself in a situation where the team complete ten tasks and no backlog item (actually, this is possible if you have ten developers) : every developer should not pick up tasks from another backlog item (story) until he completes the backlog item the first stories he did belongs too - event if the task form the other story is harder than the remaining tasks from the started sotry.
I used a lot the "hours remaining" for burndown. Team always find that tracking burndown by time is close to time tracking system, add overhead of administration and is really not accurate unless we transform humans to robots.
I am using tasks burndown (total tasks, new tasks, done tasks). Much much better. It is true that you do not see the size of the tasks that are done or new. But team meet everyday and that's where you catch problems. As well, I coach team to not create big tasks (4 to 6 hrs max). Also, I added an other chart with New tasks and Done tasks by day. Team found that the burndown by tasks make more sense that using hours.
After the team understand the values of breaking down stories in tasks, I want to try burndown by stories. So having small stories with a max of 5 or 8 story points. From Jeff Sutherland blog, this is a big step to get a team to high perform.
In addition, I'd like to mention that a burndown is just a "At a glance representation of progress". Most important and even more relevant for the team and PO's are: what is being mentioned in daily about the tasks + story progress percentages + list of impediments. After a while, management and team members don't care much about the burndown (or burn up).
We use tasks because it provides so much more granularity. Graphing only the completion of stories (which we do 5-10 per two-week sprint) will only show a change every day or two and, as you mention, won't move much at all during the beginning of the sprint.
Another useful thing my team has found is using a stacked line chart with one line for each of "To Do", "In Progress", "Ready for QA", and "Validated". This way it is easy to see any phase in the process that is creating a backup.
Use hours remaining for Sprint burndowns
- During sprint planning, estimate all the work to complete a story according to your definition of done
- Each day, developers and testers re-estimate the hours remaining for all their work (changing upwards or downwards)
- track the sprint burndown via Hours remaining - great indicator of how well or badly a Sprint is going
This is not appropriate for release burndowns as you do not breakdown all stories in the backlog, only those for the next sprint in the sprint planning workshop. So use Story point burndowns (relative size and complexity values derived by the whole team during planning poker sessions). This is a great indicator of progress towards your release.