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.
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 5 years ago.
Improve this question
We are a team of 30 people, consisting of business managers, developers and software testers.
Our developers are on different projects that have partially different - partially the same products. They help each other where ever they can. As we are all in the same room this is quite easy.
Now I asked why we do not use Scrum.
One answer I got is: Because we are all in the same room and we are helping each other. This goes quite quick and so we might not need scrum. Some of our products are developed only by 2 people. So this would be kind of weird to have a standup meeting with only two of us. Also our colleagues come to work at different times and some are doing home office sometimes.
Is it true that in such a setting Scrum is not feasible or does not bring any value to the company?
Hope for your comments, ideas, thoughts...
Best,
Marc
As literature states (see here) ideal Teamsize is between 4-8. Smaller Teams should use XP.
My persional Opinion is, yes do scrum, even if you are a single developer!
Scrum is about your customer and team and about the way how they communicate. You always talk about your team. But even more is important how is the communication with the "customer/stakeholder", how is the project management done. If you have a customer involved than have a look at these processes if they are also that good as within your dev team. Most of the problems of softwaredevelopment lay here (requirements specifiction, customer expectations, being in budget/time...)
Some aspects you loose not using scrum (and therefore I would suggest using scrum even in a team of 2). You also have to not pick everything but only theparts you like
Backlog (what is planned in the next x weeks) and its documented!
Burndown Chart (where are we standing at the moment)
Continouus improvements (in Scrum you capture impediments, you reflect what was good and bad..)
Daily Scrum (makes even sense for a single person reflecting what I did and do the next day! and what problems happened.)
Most other apsects of scrum...
I am currently starting to implement/use all this for me as a single person/developer and I can only say it makes my work and me better as a programmer. And I am even saying this, being my own customer and PO (I develop my own products/business for me)! And even than it makes sense. The advantage is, that this is with scrum all extremely lightweight (no overhead).
The Scrum Guide suggests a team size of 3-9 people.
There is a reason for the lower limit. Teams smaller than 3 people have less interaction and may lack the skills to deliver a potentially releasable increment in a sprint. It can be a challenge to keep the Product Owner engaged when you have a very small team.
My personal experience is that 4 people is a more realistic lower limit due to the impact of holidays and other absences on a team.
It is also important that a Scrum team is consistent over time. One of the benefits of the Scrum approach is it lets us calculate the capacity of the team and this is complicated by frequently changing team members.
Team members working from home and having different core hours should not be a major problem when working with Scrum. This is common in a lot of Scrum teams and can be mitigated with careful synchronisation and the use of technologies such as messaging applications and voice/video conferencing.
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 7 years ago.
Improve this question
I'm currently involved in a scrum project for a small organization.
Some events have led us to believe the organization doesn't understand their role in the scrum process. We've already gone as far as arguing about the size of the development team which, in my opinion, shouldn't be something for them to worry about (negative conclusion to this project has little to no impact on their end and large impact on us).
Learning the lingo as they go, they've asked us if they could see our backlog.
I don't have a ton of experience with scrum but is it wise to show it?
I fear we might get a lot of negative feedback because they don't understand the process all that well.
(Additional context: we are students and this situation is not covered by our classes, our teacher hasn't responded to our e-mails yet.)
Scrum is transparent. Everything the team does is open and visibile to all interested parties. Regular showcases are held to demonstrate completed work and both the sprint and project backlogs are public.
If you are following the Scrum framework then you will have a Product Owner who represents the business and is fully engaged with the team. It is the Product Owners responsibility to engage with stakeholders (i.e. other business users) to explain the contents of the product backlog.
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 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.
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
EDIT TO IMPROVE CLARITY
Scrum suggests that you split your development into a number of sprints. Each sprint being a fixed duration. At the end of each sprint you ask the client if you should release the software. If they say yes, you perform a Release Sprint, during which you do all the tasks that you woud like to do contineously, but are too expensive, such as external user testing, performance load testing and sign off, burning CDs (if relevent), writing user centered documentation and so on
In my current project we have just performend our first release sprint. We found we lost a lot of the advantages of scrum such as the burndown (as a lot of things were fixing minor tweaks or temporaraly removing security from the site so the load testing could happen), a clear goal as to how much work was to be done next etc. Basically the relase tasks were too close to firefighting to be easaly trackable via normal scrum tools.
What methods have other people used for during a release sprint, and what pitfalls did you find that should be avoided?
Actually, I prefer this tool. It does task-tracking, burndowns, burn-ups, and is useful for project notes.
But to answer the question, tracking hours-remaining on a burndown should still work. It'll still tell you whether you're going to get all your release-sprint tasks (bugs/tweaks) done in time for launch. If the answer is "not all of them", then it's time to get the product owner in to do some prioritisation, and kick some of the tasks out of the sprint.
We're using a kanban board with scrum. Each product item is represented by a post-it note on the whiteboard. Its really obvious during the daily standups where everyone is with each of their tasks, and we can see how many tickets we have queued up in the 'pending' area on the board compared to the 'done' area at the other end.
Your goal should be to get to a point where you don't need a release sprint to deploy to production:) But with that said, what are you doing in your release sprint? There are still tasks to be done, but they are even more predictable than developing code. I've never seen a difference in how the burndown/planning works other than it usually involves adding people to the team from ops. That of course can be its own problem. Maybe you could give a quick idea of what a release sprint looks like in your organization.