I have a portfolio set up for my Project in Jira. It contains 6 or 8 epics and there are varying numbers of Jira tasks associated to each epic.
The Portoflio Scope view shows the epics and the tasks under each epic but the progress bar displayed for each epic or it's linked tasks does not show progress, even for epics where 90% of the tasks are marked resolved or closed.
All tasks have Original Estimates, Remaining time and those that are resolved, fixed have time logged against them.
I cannot find anything useful int the Jira Docs for tracking progress. I presume this is down to some smal config option or some feature of the epics or tasks but I cannot for the life of me work out what it might be.
We are using the cloud version of Jira.
Any ideas?
OK, so we found the reason behind my issue. By default the portfolio Scope view was showing epics for my project with the 2 releases I was interested in. There is a More option on this filter and under that was Completion date.
By default this completion date seems to be since the beginning of: Current Sprint. This meant that all tasks marked resolved or closed were excluded from the list of tasks under the epic on the portfolio board...hence, no progress.
I'm not sure why tasks listed as completed under the current, active sprint were not listed based on the default Completed filter though? Maybe it is because the portfolio was set up based on a Project rather than a Sprint Board?
Anyway, changing the completion date to something else then meant the completed tasks were included under the epics and I am now seeing lots of green progress bars!
Related
We use Greenhopper/Jira for planning our Sprints.
A coworker want to see the changes that happens during a sprint: what tasks got, done; What tasks got added or removed from the sprint.
Is there a nice way to do that?
The only think we came up so far is to export the sprint context at the start of the sprint and at the end and compare it.
Limitations of that approach are:
If we forget to do such an export, we loose the capability to compare, since there is no way to turn the time back.
We have to juggle excel files or similar
Just go to your Agile Board, switch to Report mode (press key "3"), select the "Sprint Report" from report dropdown and right under select the sprint you want to get information about. This report shows all information you need to know about your sprint. At the top you will see the minified burndown chart, then list of completed issues and issues which were removed from sprint while you were working with it. Issues with asterisk are those which were added to a sprint after it's start. See the following link for more information https://confluence.atlassian.com/display/AGILE/Viewing+the+Sprint+Report
Based on this answer the model for the TFS 11 burndown chart is for tasks that a children to stories.
How can I display a burndown chart of the currently opened bugs during a sprint without having to create subordinate work items for them?
The way it is intended is that you add tasks as children of the bug as soon as the bug is added to a sprint. These tasks will drive the burndown. This is the same for Product Backlog Items and it is very simple through the web ui. The estimation data in the bug itself will be represented in the release burndown.
Should you want the bug itself to function as a task, you can either:
Use a task workitem to log bugs. This is very common for bugs found for work that is ongoing in the current sprint. It's just a bit of extra work to achieve 'done'.
Update the work item definition for bug to have the proper states and fields, and add it to the task category. The process is mostly described in this question.
You should also keep in mind that bugs found for work that was done in a previous sprint should only be picked up in the current sprint during the sprint planning meeting, or when it is critical to fix it as part of the current sprint. In the first case, treat it as just any other PBI and break it down into tasks. In the second case, go fix it immediately, don't bother about the burndown, the bug is critical and should be fixed now.
Perhaps it is more psychological than programming question:
We use JIRA with Greenhopper in our work, so when I receive new tasks I see them at the Agile Board for current sprint. For every sprint I have a LOT of tasks, after I have fixed, for example five of them I set their state as need test and these tasks go to tester (he has not only my tasks to test as usual). If these tasks are tested and all is ok they closed by tester. The problem is - that I could not see how many tasks I have done. When they are closed they disappear from my Agile board and I see only new tasks there... Imagine - yesterday you have completed five tasks for current sprint, but today chief adds ten more tasks in this current sprint for you.
So: Number_Of_Tasks - 5 + 10 = Number_Of_Tasks + 5.
And thus the Agile Board has no visual progress for me - it grows in size. This is very demotivating
In short: How could I view my done tasks?
You probably have the "Hide Done Issues" button ticked.
Go to Agile > Task (Greenhopper Agile plugin needed)
Above your Task board. One is "Hide Done Issues". Click/Unclick that.
Your Done issues will now be displayed.
Imagine - yesterday you have completed five tasks for current sprint, but today chief adds ten more tasks in this current sprint for you.
As for this, your chief needs coaching. If you are doing SCRUM, then the "chief" (whoever that is) should not add extra work to your sprint. If you finish your tasks early, you should pick some off a teamate who might have run into trouble, or you can test his stuff. The point is to achieve the goals you (the team) have set for yourselves. If everybody is done, then the sprint finishes early. Good for you!
You can finish and replan the next sprint or teamates should pick off stuff from the backlog themselves.
The danger of a "chief" assigning you stuff is that these micro-managers may not have a detailed understanding of what has been done, what is to be done and what is un-tested and might be reopened by a tester.
You can use a Jira query as a filter. The query itself would look like this:
status WAS "Need Test" BY currentUser() AND status = Closed
... yes, quite like SQL. ) Here's the official documentation link.
We recently finished our first couple of sprints and some questions were raised to which we don't quite know the answer.
Both questions are related to: what should we do with backlog items, tasks and bugs which are not completed when the sprint ends? And how will a certain action influence a burndown or velocity chart?
If we have a 20 day sprint, my guess was that we should start on day 1, stop on day 20, leave one day for the next sprint meeting (day 21) and start the next sprint on day 22.
Let's say we have a PBI which has 3 tasks. One task is Done, one is In Progress and one was put back to To Do. The PBI has an effort of 6. If we move items in or out of the sprint during the sprint this has an influence on the Sprint Burndown and the Velocity chart. But once the sprint ended, and we move these items, does it still affect the charts? Or how should we handle such items? Should we close the PBI (set it to Done, even though it's not) or just move it and leave the tasks that were done in the previous sprint? Should we set all tasks to Done, even though some aren't? Each task has been worked on, so hours were used. We need to keep track of those, or at least, the velocity chart should still be OK.
A similar question rose for a bug. We added a Testing state, so instead of setting the state to Done, the developer sets it to Testing, so the test team knows which PBI's or bugs to test, and sets it to Done once it's completed. If a bug arises from a PBI, we close the PBI and open a bug for it. But if it's a bug, and it's not fixed, they reopen it. Either by setting it to Approved or Committed, but what happens with the efforts that were assigned to it? If the bug is not fixed when the sprint ended, should we set it to Done and open a new one, or just move it to the next sprint?
Scrum has been slightly revised and clarified over time; the latest version is more or less specified in The Scrum Guide (2011)
The Sprint Planning Meeting is part of the Sprint and it typically performed on the first day of the sprint (Day 1). Day 20 Will contain Sprint Review and Retrospective. Day 21 is actually Day 1 of the subsequent Sprint.
Regarding your question about the unfinished Product Backlog Item (PBI): Your goal is to establish a velocity for your team over time. CONSISTENCY is key to this. So most importantly, you should establish a way of doing it the same every Sprint. I see teams handle this is different ways; You need to determine if you actually delivered the Sprint Backlog Item based on what got done. If the value wasn't delivered, then you can leave it as not done and optionally update the final work on the tasks. You can also put a note in the history and/or description of the Sprint Backlog item about what was accompished and the acceptance criteria achieved. If the value of the item was delivered to some degree then you might make a similar note and count the item. You need not be exact about the points covered in the Sprint since they will average out over time, so you just need to use your judgement. Whatever is not done can be made a Product Backlog Item and prioritized accordingly. Your Product Owner may decide to put it lower on the Product backlog depending on the value of what was not finished in it. When the PBI representing the unfinished work, you will create a new set of tasks for it (you might copy the ones that were not completed from the Sprint in which they were not completed to save time). What is also important here is to discuss how things went and how you can handle this moving forward during your Sprint Review and Sprint Retrospective so your team can adjust accordingly.
Regarding the Bug, you might consider handling it similarly to the PBI for planning and prioritizing and Done / not done; your team needs a definition of done; if this includes testing, you should consider it Done only after testing. If it is not done then again you should handle that in a consistent way. Out of the box, the Scrum 1.0 version of the Bug work item has a state named Committed that indicates that the Bug is ready for testing, so you shouldn't need that testing state. Once it passes testing, it goes from Committed to the Done state. You can find the Process Guidance for the Scrum 1.0 template on the Microsoft site. It is more or less the instructions for how to work with the template.
I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.
So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?
Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.
An excerpt from MSF for Agile Software Development v5.0 on MSDN:
You can assign the area and iteration fields to most work items based
on a process template for Microsoft Solutions Framework (MSF). You
specify values for the area and iterations fields when you create a
work item or during a review of the product or iteration backlog. If
you defer a work item to a later time, you should change its iteration
accordingly.
And from the work item definition guide:
In the Area and Iteration lists, click the appropriate area and
iteration, or leave these fields blank to be assigned later during a
planning meeting.
Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).
You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work. If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.