Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I know something about scrum and project management. For ex. We need to findout all steps of program and write down with their prioraty and work hours. But I don't know how to draw burn down chart for one sprint (which values do we need and which calculation creates the chart?).
You need
the duration of the sprint (in days). This is the x-axis.
the sum of all task-durations within a sprint. This is the y-axis.
Now you can calculate the ideal-line. On the first day no task is accomplished. On the last day all tasks should be accomplished.
The chart draws the task-hours that are not accomplished for each day.
That's it.
Here is a whole tutorial I wrote up on managing burn down charts including a google docs template and a microsoft excel template
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
which values do we need and which calculation creates the chart?
I guess crauscher already answered this question but I just wanted to say that there are tons of tools out there which can create the burndown for you automatically. All your Team has to do is enter and burn down hours during the Sprint. Although Agile suggests to prefer interactions and use less tools, if you really want to scale as a project/company you would need some sort of Agile project management software. A few I can recommend are : Scrumworks, Piviotal Tracker, Agilex.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We have a project which is deploying thorough Scrum. In Scrum you will update your estimates during the sprint and set them with the remaining time. We use youtrack for tracking the project and particularly its Agile Board. We used to update estimation -as I told- during the sprint with remaining time.
But I found that decreasing the estimations (when work goes on and estimate of remaining time should be decreased) wouldn't be reflected in burndown chart. It just draw that chart by sum of Whole sprint tasks estimation and sum of fixed sprint task estimations. A change in estimation will just scale whole chart, not be reflected as works goes on.
How should we change our estimates to watch it on burndown chart?
In 5.0.* version youtrack's burndown chart doesn't relies on 'old' estimation values. Ideal burndown and issue estimations values are taken from current values. In 5.1 it will have such ability (http://youtrack.jetbrains.com/issue/JT-22390)
If I'm understanding the question correctly, you need two fields. Original Estimate and Remaining Work. This will allow you to keep track of the % complete of the original size.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are following Agile development methodology. As a SCRUM master, I am maintaining the Sprint BackLog. I want to know what is the best practice to accommodate any increase in effort for a particular task in the middle of a project.
For example, I am doing ABC task and in the starting of the sprint I have estimated that it requires 10 hrs to complete it, but on the second day I realized that it requires 20 hrs, so how will i update the Sprint Backlog.
You change the remaining work to 20 hours. Scrum is concerned with the actual work remaining, not whether the original estimate was right. That's important, but it's not explicitly part of Scrum.
If this threatens your ability to deliver on your commitment, then you need to discuss solutions with your team and possibly also the product owner. Perhaps:
A teammate might have a simpler solution.
Other tasks were overestimated and you can still deliver everything.
The product owner might decide it's not worth the effort.
Sprint planning was rushed and the sprint should be declared a failure and restarted.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Our software company receives literally hundreds of support requests per day and there's a whole team working on our inbox. How can we gain effective metrics that map directly to our Scrum backlogs?
If we're too specific, the team has too constantly beware of changing metrics, if we're too general, the PO has to sort through too many emails to get reliable priority.
Any ideas?
What do you mean by "support requests"?
Assuming 3 broad buckets:
"How do I do x?" type questions
"This isn't working right" (i.e. a defect)
"It would be really helpful if it did y." enhancement requests
Within each of the categories (you may have more or less than 3, but 3 is a good number to work with), assign some tags that categorize the request. I like to organize the categories as labels for vertical columns, and put a 'flag' for each request in the column. This give a quick and dirty vertical bar chart, and I almost guarantee you'll see a Pareto ratio emerge, wherein 20% of the 'tags' result in 80% of the requests. Now your PO can prioritize among/across the 20% of each of the 3 broad buckets, knowing that they are the high-value ones.
You can keep this as a running exercise.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We have now installed Agilo to manage our Scrum projects, and we have that proble: we can handle just one backlog. How can we have different backlogs?
Thanks for your time!
Maybe you should try other tools? :)
Here are some other tools you might like to try.
Installable onsite are Rally, Version One. I think Thoughtworks' Mingle is available onsite but they prefer to host it for you.
You may also like to try some of the new online Lean tools: LeanKitKanban, AgileZen.
If possible, get one or more big whiteboards and some post-its, then back it up / produce reports etc. electronically. Excel worked well for this for me. Also there's nothing like the tactile and immediate visual feedback from moving post-its around. You can use index cards and holders or blue-tack if the post-its fall off.
You can also represent the multiple backlogs at different scales; for instance, showing whole features, apps or systems completed at a project or programme level while tracking the smaller stories and tasks at a team level.
Do you have multiple products? There should only be one product backlog for each product - having more than one doesn't make much sense.
To break down a product backlog, it often makes sense to add extra columns to the backlog for different categories within that product. That would make it easier to filter and see different areas of the backlog quickly and efficiently.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Which organisations are best suited for use of Scrum methodology and why?
Scrum is not a development methodology, it is a project management methodology. Scrum is about managing workload and resources, and removing impediments to progress, and surfacing results at regular intervals to the whole team (including stakeholders).
Think to yourself:
could your dev/project teams benefit from a daily or bi-daily catchup meeting?
when you have design or project meetings, do the wrong people hog all the attention?
do you need to draw a distinction between various stake holders in a project?
could your team benefit from an iterative process, where "releases" are done frequently (i.e. every 3 or 4 weeks), and bugs and features are carefully prioritised against each other by the product manager?
The smallest team we have that uses something scrum-alike consists of 3 devellopers (2 full, 1 part-time), the stakeholder and the scrum-master ('secretary'). It works very well and we are planning to switch other small project teams to this method soon.
There are some 'points' you have to keep in mind:
We have the project status in an excel table under revision control, that is updated at least after the very short daily meeting.
The review and planning meeting is scheduled biweekly on a given day and will not be moved until all participants agree.
In all metings we break down the tasks from backloglist to smaller ones of max. 2 days of work, depending on the task type (concept, prototype, product etc). This proved to be the most valuable means to get reliable estimations!
If the stakeholder needs an status update or needs to adjust priorisation he can have a look at the excel table and change it, so even if he's not participating the planning meeting he has enough impact on project devellopment
The most important influence on management style is that you have evidence on what a given change would cost and what you can achieve until a given date (thing of a release date or a fair trade).