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'm developing an app for agile projects management, and I'm wondering what is the measure unit of a Burndown Chart... Wikipedia's article states that it measures the number of tasks remaining each period of time, but I've seen people using it with tasks, features, function/use case points...
Is there a measure unit that is considered "right" or standard between these? Or is it all by choice?
Simply, the burndown chart shows work remaining at a point in time.
The x-axis is usually time and the y-axis is usually work.
For a Sprint Burndown, time is most often expressed in days and work is expressed in task hours
For a Release Burndown, time is often expressed in Sprints and work is expressed in Story Points
I have typically seen brundown charts in terms of story points. Story points are used as a measure of complexity of a story and is a numeric value with no unit.
The burndown chart starts at the agreed upon velocity on the y-axis and burns down to zero as a function of time. If stories are added during the sprint you may burn into the negative numbers of the y-axis to represent the total velocity.
The goal is to have the burndown follow a linear trend line, but that is hard to achieve since it would mean that everyone must complete the same amount of points per time unit every day
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 1 year ago.
Improve this question
In a user story mapping session, we should start by Identifying the different user types, then their goals or outcomes (represented on the map as activities), and the goals or outcomes of the company (represented on the map as versions or releases).
So for me it makes sense to try to deduct backbone tasks from user activities.
But in his book, Jeff Patton has an example (Everyday life) where he does the opposite, he first list all the tasks, then group them by higher goals or Activities.
So I am confused. From top goals to tasks, or from tasks to top goals ?
From top goals to tasks if you want to deliver fast.
Doing "As an HR manager I want to see turnover reports so I can better focus staff retention initiatives" first instead of starting with (e.g) a "Build CI/CD pipeline" task is the way to go.
That's because it eliminates waste and invites iterative problem solving: "At a minimum, what do we need for continuous integration/development so the HR manager can get her report?" is a great starting point. Go live on production with that, than beef up CI/CD as needed for the next story.
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 4 years ago.
Improve this question
I am new to Scrum and I am trying to use it for website support and maintenance.
For website support and maintenance, we often receive small tasks, for example: replace a banner on homepage, change phone number on contact page, remove image xyz on article 123, etc... I don't know how to deal with these small tasks in Scrum.
At the moment, I create a single task in backlog, and a single Sprint for each task. Then, execute each task individually. Am I right?
In Scrum we have fixed length, repeating sprints. We bring work to the sprint, rather than creating sprints from tasks.
This is useful for a number of reasons, including:
After a while we get to know the capacity of a sprint.
We know at the start of the sprint what we will be doing and there is no change to the sprint goal during the sprint. This stability helps the team get organised.
The regular cadence helps the team get into a rhythm of planning, executing and then adapting.
Scrum isn't as effective if:
You don't have a team of 3-9 people
Work items and priorities change frequently and stable sprints are not possible
From your description, I wonder if Scrum is the best agile framework for your team.
Perhaps you might consider using Kanban?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to make a chart to visualize our product backlog over time. My idea is to show a line (a "series") for each work item, with each line having a width according to its estimate, and each line stacked on all the other work items that are ahead of it (as of each day). So on any given day, a line be at a Y-axis height representing how much work is ahead of it on the backlog.
The problem is that the ordering changes day by day, so I'd need to have the series cross over each other, and I haven't been able to find a charting tool that will let me do it.
(I'm trying to demonstrate the high-level "flow" of work items - the ones near the top of the queue will keep getting done, but the ones near the back of the queue will just sit there for a long time. New ones will be introduced periodically, and old ones will be canceled. I imagine the rendered chart will look like streaks of wind, if you will.)
Is there a way to do it in D3, maybe?
Pretty much any chart visualization that you can think of can be done with d3, it's just a matter of execution.
I'm not positive exactly what you're describing, but is it something like this baby name chart?
You can look through the gallery to see a lot of different examples of what is possible with d3.
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
This may be a weird question and please bear with me, I am completely new into this.
I have a list of 20 requirements (use cases) which I received from my client. With him, I prioritized this list of requirements (1 highest 3 lowest). I wrote for every requirement a use case scenario (rather than user story). I also have a use case diagram and some technical designs (class diagram, database diagram).
Now, my plan is to separate this list of 20 requirements into 5 sprints. Each sprint lasts one week.
During every meeting with my client, I can show the product with 4 new use cases implemented. If one of them isn't finished, I move it to the next sprint and my client can request a change during this meeting. During this change, the specific use case diagram and classdiagram/database diagram may be changed.
Is this considered to be Agile? (Even though he gave me the full 20 requirements from the start of the project)
Agile is sort of a big tent, but I would not apply that label to the process you've described. You are describing lots of upfront design work and a full specs up front. The schedule assumes all the req take the same amount of time to implement, thought you acknowledge that it could slip.
The primary agile feature I see is the tight (weekly) feedback loop with client.
I recommend trying on http://pm.stackexchange.com.
This is not considered as Scrum:
- Schedule is prefixed (5 sprints).
- Velocity is prefixed (4 use cases/sprint).
- No scrum ceremony is followed as such.
- All requirements are given upfront.
Please refer - https://www.scrumalliance.org/why-scrum/core-scrum-values-roles
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 5 years ago.
Improve this question
I am working on a project to pull out data from rally and create a velocity chart.
I understand the REST Web Service APIs to use are Defects, Iteration, Hierarchical requirement and Iteration cumulative flow data.
How are the calculations are done to calculate the velocity per iteration for a particular project?
What data is required and how can it be achieved? Right now I'm able to pull plan estimate of all accepted user stories and total plan estimate.
I wrote an app recently to calculate velocity. I used the story points of all accepted stories/defects in a time period (iteration/release). My numbers ended up matching what Rally had for my velocity, so I believe that is all it takes.