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 have a product backlog with some features and a sprint backlog which includes tasks for these features, and also such tasks which are not directly related with stories in product backlog (for example, testing, "to connect to db", "to do interface design" and so on). How can I calculate the velocity then?
You have two options:
Estimate them and treat them as planned work. Not ideal, since these "tasks" don't yield direct value ot the product backlog, but it sounds like work and the product backlog contains all the work that could be done to deliver the product...
Ignore them and treat them as overhead, your velocity will be lower, but that's ok, the velocity then tells you how much work you've been able to deliver that adds value. These other tasks are just "overhead". Or they'd be part of what's commonly called Refinement.
Of course the better solution would be to slice your work in such a way that these tasks are part of delivering the value for that sprint.
Related
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
We develop products and want to use SCRUM for development. We start with business case, high-level business analysis and technical outline that all contribute to and form the backlog items.
So after a month or so, we have the high-level features captured in the product backlog, keeping in mind it might change. So now we should decide on the team...how should I do that? How to tell whether 2 or 6 are needed, what is the best practice?
Usually SCRUM goes like this:
Depending upon the backlog and complexity of tasks a development team of 4-8 individuals is created which typically includes designer, architect, developer, tester and a scrum master (tasks like: analysis, design, development, review, testing & technical documentation).
You can decide on sprint cycle's length including a separate planning period
In planning period you assign tasks to individuals and the effort estimates based on availability of resources and time
After planning, you track the progress of tasks and update your backlog list accordingly
As SCRUM is supposed to be self organized, there are times when you might need some interaction from project managers or domain experts.
After each sprint cycle, ideally there should be some dedicated time for sprint analysis which can give inputs to next planning phase.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
We are following Agile SCRUM methodology in the project and we came accross a huge user story that spans accross 2 sprints. How do we report this item in the burn down chart? Which sprint backlog should this user story belong to?
User Stories should always be broken down into work items that can fit within the timeframe of the current sprint.
Bring the story to your team and ask them how they would logically break it down to work on it iteratively. Based on that feedback, you can create multiple stories from the original parent story to represent the work and then prioritize/estimate them separately.
In terms of backlogs, you may need to track a Program-level epic backlog with the larger user stories that are being discussed and prioritized with the business stakeholders. If that is the case, you'll have your epics in the Program-level backlog that spans the entire Release. As the stories become more firm and detailed, you can move them into the team's implementation backlog.
I've seen some Product Owners actually maintain a separate excel spreadsheet for the "Business" view of the backlog and just keep their standard backlog for the team with only the broken-down user stories.
The sprint burndown chart indicates how far you are from meeting sprint goal. An uncompleted story will inevitably mean an unfinished burndown curve at the end of the sprint, you don't need to do anything special about it - it's just the state of the iteration.
At the end of a sprint, an unfinished story is typically carried over to the next sprint and thus changes backlog. Depending whether your burndown chart reflects stories or tasks, add up the unfinished story's points, or the unfinished tasks' estimates with the rest of the sprint items to get your Todo total and draw the ideal trend.
You should note though that a story spanning 2 sprints should be accidental and not planned on purpose (split it into smaller stories instead).
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
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).