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
Does the product owner actually vote on the size of the story in Scrum or is it just Dev/QA?
I was wondering, because it does not really seem like having the product owner vote is productive.
In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.
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 3 years ago.
Improve this question
I am bit confused with a question, The customer can see the sprint goal, but should he be also able to see sprint backlog? or it is not allowed for the customer to see sprint backlog?
One of the Scrum Values is Openness. Scrum does not specify what a customer can and cannot see. However, you can apply the value of Openness as a litmus taste to a decision about what to share and what not to share.
Customer can see the sprint goal, and Release goals. To me thats enough for a customer view. Sprint back log must be visible to the team, scrum master, product owner and other engineering stakeholders only. Anyways its agile, as long as you give access to your backlog anyone can see the backlogs.
There is a great deal of value in making the sprint backlog visible to everyone.
Reasons for this include:
Helps to set expectations on what will be done in the sprint
Creates trust between those in the team and those outside of it
Allows for feedback from stakeholders to the Product Owner
It can protect the team from having additional work dropped on them - it shows that they are busy and what they are working on
First of all of we talk purely Scrum book terminology, I don't think there is such party as Customer. Scrum defines three roles: Development team, Product Owner and Scrum Master. You can argue Product Owner represents customers but this is not really outlined in Scrum Bible.
Sprint backlog as an artifact is generally managed by the Dev team as this is essentially what's been committed to a sprint. So the only restriction I can think of in regards of Sprint backlog will be its modification. Changing it during sprint is only allowed if Dev team makes an agreement with the PO.
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
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).
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
What approach did you take to describe the benefits of SCRUM to clients / business units who do not have a technical background? Please list any analogies you thought were useful. Finally, how did you address the concerns that the Waterfall camp had?
I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.
Using a incremental process significantly reduces the risk of wasting money on something that's not gonna be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles. The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?
Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.
You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction.
An additional point is protection of investment - with traditional approaches, a system typically "ages" with time, its value decreases, and maintenance costs rise until it's no longer feasable to maintain it. With an Agile approach applied well, the code should be maintainable and extensible indefinitely.
Here is a good, short video on all three points: http://www.youtube.com/watch?v=OWvSnYjqOTQ
I would mention the benefits of focus. Because the guiding principle of sprints is functional focus and shipability, all details (e.g. ergonomics) need to be taken care of, whose fixing would otherwise be postponed under pressure in more global approaches. You don't have it all but what you have is solid. Non technical people appreciate that because it reduces risk from their point of view: it injects honesty and trust, together with interactivity, in the dialog with clients.