I want to know whether I can perform capacity planning based on story points entered in User Stories and not based on hours entered in Task. This way I don't have to define hours in task. I will just enter task under each User Story and leave the planning fields blank in Task.
Also, I want to understand whether I can generate Burn Down chart purely on the basis of story Points.
Can:
Use the Stories Backlog for Analytics, which will present burndown in Story Points
View the Point load on the Sprint, while on the Sprint board, select the menu item "view options", select "Side Pane" = Planning, this will display points aggregated for each sprint
Use Velocity charts to map your story points across sprints to train your team on Story Pointing and Team Capacity
Cannot:
Use Story Points in capacity
Related
I'm new to Jira so maybe my question is trivial. I need to get a statistics about a whole team and individual members. Currently I'm mostly interested in a mean time a person spends on a task (all our tasks have similar complexity).
How can I get this information in Jira? (Currently we don't arrrange sprints, we just create tasks and assign them to developers.)
On your filters you can show the attribute "Time spent" as column. Click on the top right on "Columns" and search for this attribute to enable it on your filter list.
Furthermore you can add Gadgets to your Dashboards. I see two gadgets here:
Resolution Time
Time Since Chart
I am using Greenhopper in Jira and I have a user story of 25 points which has a number of tasks.
I see there is a 'statistic burn up chart', so my question is if after 3 days of the sprint I have burnt 5 story points where do I indicate this in Jira? Is this done on allocating story points to task and then closing the task?
You don't. A story is either complete or it is not. The Greenhopper 'report' Burndown chart on the Agile board only shows burn-down at the end of each story. A story doesn't 'burn' as you work on it, the sprint 'burns' as you complete stories.
25 points? You must have some pretty high-precision estimating going on.
There are a lot of different, yet still correct ways to manage stories in JIRA. It is generally accepted that a Story isn't complete until all its subtasks are done, it can still be useful to track progress of the subtasks. So here's how I do that today:
We divide all of our Stories in subtasks (technical/implementation tasks), and apply hour (time tracking) estimates to each of those. We estimate story points way in advance, then do more detailed estimating of subtasks and hours before starting each spring. During a sprint we use the hour/timetracking field as our more detailed tactical tracking field that stays day-to-day current.
Greenhopper then lets you view charts based on hours or points. So we use the point-based charts when looking at the overall project, but the hour estimate field for tracking our tactical progress in a sprint.
Hope that helps.
To manage the scrum development process of a big community website, we decided to move to JIRA/Greenhopper/Bonfire.
I have created elaborate Epic, Stories and Tasks, all well linked to each other.
I would like to develop the "Product Story" in more detail all the time by adding new Epics, new Stories to (new or existing) Epics, etc.
To be able to do this properly, I want to have a hierarchical overview of all issues: Epics, Stories, Tasks, etc.
Question: How do we set this up in JIRA?
Why?
=> My approach is from the point of view of project management: getting everybody aligned around the same vision. However, I think it is part for everyone in the team -especially for the ones who are actually building the product- to have a quick view of how their current or planned work fits into the big picture.
Stories have sub-tasks, which will be shown hierarchically in the Sprint, but all sub-tasks have to be completed in the sprint of the user story. I also think when you create a story you can specify an epic, which will create a hard-link ( the same as story -> sub-task). Is there a reason you want to use a Jira task? To me it looks that in a SCRUM environment you only need Epics, stories and sub-tasks. Maybe some spikes and support tickets from time to time.
Coming from a tool like Rally, I can appreciate you wanting to see the big picture. We transitioned from Rally to Greenhopper over a year ago mainly because of costs. Lets just say you get what your pay for. I haven't found the feature you're looking for in Greenhopper, it only has a single threaded view for things like Epics to Stories (on the planning page) or Stories to tasks on the (on the work page)
In a SCRUM Agile project we use TFS 2010/VS2010.
In the period before starting this project, the customer has already written out 80% of all the use cases. The issue is that most of these UCs are so large, that I want to split them up in user stories. The user stories can be compared to scenarios for the use cases.
My plan is now use the Agile process template and start creating top level user stories as use cases. Each top level use case will have 1 or more user stories as child beneath the parent user story. Then below the 2nd level user story I add one or more tasks where developers can do their checkin against.
Is this the right approach ?
Yes it is, the proof is that when you create a child work item from a User Story only two types are available: Task and User Story.
This is made to split big User Stories into a subset of smaller ones.
I have installed TFS 2010 using the Scrum for Team System v3. The work item templates want you to enter a Project Backlog Item that includes story points, then you need to add linked tasks as a child of the PBI. It is at the task level where you can assign team individuals, update estimated hours left, etc.
What is the importance of the Story Points used at the PBI item if individual tasks are using hours?
Has anyone customized this template so that the child work item tasks use story point burn downs instead of hours? Also, I would be nice to have the total number of story points from each individual task roll up into the PBI item as a read only field for total story points.
Thanks for your time.
The company that I work for is also using TFS 2010 with the new Agile Template v5.0. We are going about the process in the following way and having some success. The hardest thing we have done to date is try to wrap everyone's head around the idea that Story Points do not directly equate to any form of hours.
We start the process with a Release Planning meeting, this is done once a week but if you have never done one you probably want to start with one first. We have 3 teams and only the product owners and team leaders are in the meeting, it would just be to large to manage if we were all there. It is at this Release Planning meeting that we, the team leaders only, play planning poker to assign Story Points to User Stories.
Then we have a Sprint Planning Meeting where a team and the Product Owners and Stake Holders will agree to a number of user stories to execute one in a sprint. The Story Points, after a few sprints, give you an idea of how many you can actually don in one sprint. Each User Story is discussed with the product owner and usually the Scrum Master is adding tasks to the User Stories as they hear the team talk them through.
Now the Product Owner and Stakeholders go away. The Team then goes about dividing the work amongst itself and assigning hours (Original Estimate) to each task. After that is done the Team goes to work, usually two weeks but I can see us doing a three week sprint if the sprint just couldn't be nailed down to two weeks.
As we work we adjust the Hours Completed and Hours Remaining with no regard for the original estimate. If we have spent 3 hours so far and after 3 hours we think it is going to take 2 more that is what is on the task, it doesn't matter that the Original Estimate was 4 hours.
Because we have "filled in the boxes" and not adjusted the template all of the reports and the cube just work. We don't need to make any large adjustments to the reports or anything to capture some really nice metrics. If you want a template that is simpler you should take a look at the "Microsoft Visual Studio Scrum 1.0" from the Visual Studio Gallery. It is simpler for sure but offers less reports and less support in the way of integrated Office documents.
Mircosoft Visual Studio Scrum 1.0
We ended up using the TFS Agile template, but just ending up using the "Effort Hours" in the work item tasks and refer to them as story points.