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
My organization is currently implementing Scrum. While working on a product backlog item to change the way some business logic is processed, we realized that some of the business logic is flawed. The PBI and its acceptance criteria are currently oriented towards modifying the implementation of the existing business logic. The PO feels this change to the business logic itself is a high priority and should be worked into the sprint somehow, and the dev team agrees, especially since it would make a lot of sense to do both things together, from a development standpoint.
We are unsure, however, if it would make more sense to modify the acceptance criteria or create a new PBI and pull it into the sprint right away. I personally lean towards a new PBI because I feel like this is a separate story and set of acceptance criteria from the original PBI, and I'm skeptical about changing acceptance criteria mid-sprint in general. The PO pointed out that both this new requirement and the original PBI will be implemented at the same time, and the original PBI is pointless without the new requirements to be addressed. So the PO feels it would be more appropriate to adjust the acceptance criteria of the original PBI instead of creating two separate ones that reflect the same implementation in the end.
Is one of these approaches more scrum-appropriate than the other?
You should modify stories only with the concurrence of the team, because they committed to delivering one set of criteria. If you change the criteria without the team's unanimous consent, then why are you bothering to have gotten it in the first place?
It's a big deal to fiddle with the sprint backlog, because then you're devaluing the team's commitment to deliver a particular set of stories during the sprint.
If the team isn't willing to accept the changes, the PO can withdraw the original story and put a new story at the top of the backlog. It might be included in the current sprint, or it might not.
Resist with every fiber of your being the notion that the PO can fiddle with the sprint backlog during the sprint. My PO tried to drop a really tiny story (based on some very bogus reasoning) near the end of a recent sprint.
From http://www.scrum.org/scrum-guides/ :
Only the Development Team can change its Sprint Backlog during a
Sprint.
I think that's good advice, and you should disregard it with great trepidation.
There are some subtle differences to understand with Scrum.
In Sprint Planning, the product owner gives the next highest valued requirements to the team that he/she wants delivered based on the teams velocity. The PO explains the requirements and the team question the PO on specifics.
Note: This should not be the first time the team is seeing the requirement as they should have seen it before in grooming sessions.
The team discuss their approach, do their designs and create a heap of tasks to do and agree to the forecast. The team produce a sprint backlog, sprint goal and start working.
No-one can change the core requirement the team is working on; not even the team. Only the PO has the right to terminate work if he/she sees no value in continuing with it. There is a fine line here between bad planning on the PO's side versus clarification of the requirement.
The requirement is not a contract, and the team should have the core just to what has to be done. Details should gathered and work slightly altered to get the requirement done. The team can fully change the tasks they are working on, add more tasks or remove tasks to help communicate and collaborate; only as long it is to deliver the requested requirement. Clarification of details is totally acceptable.
The challenge most teams have is where clarification, changes the meaning of the requirement. When this happens, you should nip the issue in the bud in a retrospective and adapt to the way you write requirements; thus removing ambiguity. It simply means you need to spend more time grooming.
To answer your question. Please if the PO and the team feel it makes sense to alter something ... do it. However, this should be more the exception than the rule. If it is occurring all the time; your grooming is bad. There is nothing wrong with clarifying acceptance criteria and enhancing quality in Sprint.
In this situation, we normally let the Product Owner drop the original user story from the sprint, which frees up time in the sprint. With that free time, the PO can request that the new user story (with updated acceptance criteria) be included in the sprint. There is an assumption of course that the new user story can be completed in the sprint's remaining time.
By splitting the process into 2 separate steps, it ensures that the PO understands that some work must come out of a sprint before more can go in, making the process resistant to future scope creep.
Generally, changing AC for a ticket (PBI) is a big no no once a ticket has been estimated, especially within a sprint. That being said, you have to ask what problems it can cause to do so.
Namely changing the AC could cause the estimate to be incorrect - namely too low. So what? Well, that could cause the team to fail to complete the committed tickets from the sprint. That's bad.
A new ticket in this case is probably a bad idea because it doesn't sound like it would fit the "independent" criteria of an INVEST story.
Modifying the current ticket might cause some accounting issues for you when trying to track added stories/points for the sprint, but other than that I don't see any issues. The key here is to re-estimate so everyone understands this is more work.
Try not to get bogged down in what's "scrum-appropriate". Think about what works, what problems different things would cause you and make your decision based on that.
Finally, make sure that this issue comes up in the retrospective so you can discuss why the AC was incorrect or incomplete in this case and see if the team can take actionable steps to prevent that from happening in the future.
PS you may find more help with questions like this over at pm.stackexchange.com
I have gone through your question very quickly. Here is the thing. We have had similar situation. We created a delta story and pulled stuff out of the current sprint and moved it to another sprint. Just call it DELTA US and give version 1.1.
Does it help?
Thanks,
Kris.
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
I work within an agile team.
We have a released product and we are still working towards a future release.
Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product.
Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets).
My question is how do you account for the maintenance hours during sprint planning.
Currently we have a story called maintenance buffer where we allocate some hours to solve tickets. And we sort of use it as a buffer, so in sprints where we receive no tickets we use the hours in the buffer for development work.
I feel this is not a good agile way to do things, any suggestion?
The approach you have mentioned is also covered by Mike Cohn in Should Story Points Be Assigned to the Agile Defect Story?, where he writes:
Sometimes teams write a user story for this activity such as: “As a
user, I want at least 15 bugs fixed” or, “As a user, I want you to
spend about 50 hours this sprint fixing bugs so that the application
becomes gradually more high quality.” Even a team that doesn't
explicitly write such a user story will usually include a row on its
taskboard to make the agile defects and bug fixing visible, and to
track it.
You currently have a story called maintenance buffer where you allocate some hours to solve tickets which is something similar to what is stated in Mike Cohn's article where he recommends to assign points to bug fixing the agile defects.
There could be other options too, like
Setting some time for bug-fixing in each sprint. It could be a set time of the day/week when every team member deals with bugs.
Including each bug in the same sprint backlog by considering them as a partially implemented feature. This is discussed by Mark Summer in Managing Bugs in Scrum.
What to do in case of emergencies / hotfixes?
You need to assess the criticality and the effort required to fix that urgent bug. It is up to the Product Owner to decide if the team drops everything and starts working on the hotfix. Reason being that the customer always comes first and if the delivered product is not providing the expected value then there is no use of adding more features to an incomplete product. No framework / methodology stops you from handling exceptional cases or dictates you to ignore critical issues. So the current sprint can be cancelled or if the hotfix can be handled by one (or some) members of the team then a feature or bug, from the current sprint, can be swapped with the urgent bugfix.
In words of Geoff Watts from Production Support and Scrum:
If the issue is a true emergency, the Product Owner should have the
authority to play the “emergency card,” as long as he is aware of the
costs of doing so— not completing the items we planned to and,
potentially, jeopardizing the sprint goal.
The Product Owner can exercise any of the 3 options:
Add the urgent defect to the backlog because he/she has decided that the current sprint goal has higher priority
Add the urgent defect to the current sprint because it is critical enough which could even jeopardize the sprint goal
Cancel the current sprint, do the hotfix, and then start a new sprint after that
In brief, I'd raise bug(s) as a Product Backlog Item (PBI) and prioritise them against other PBI's in the Product Backlog. This way, you can always be sure that the most important things are done first.
Part of the unwritten contract of Scrum is that the business agrees not to interrupt the Development Team. This is partly how they can improve performance.
If you get a hot/urgent ticket that CANNOT wait for the duration of a Sprint, you need to convince the Product Owner who would then negotiate with the Development Team for the best way to introduce the hot item.
However, this would need to be an exception, rather than the rule. If, as you imply, you get a lot of bugs to fix, I'd be tempted to run the maintenance / defect fixing with a separate team using KanBan, rather than Scrum.
I agree with you that this is not a good agile way to do things! The question to ask is - is your real objective to plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?
I would go one step further from what Derek has suggested - and use Kanban AND Scrum together - Scrumban is increasingly catching on! Since you have said you may have 0 to 5 defects in any sprint, clearly your 'failure demand' is variable and so is the need for your 'maintenance engineers' capacity. What do they do when there are 0 or 1 or 2 defects? I presume they also contribute to the 'value demand' - new user stories.
This is where Kanban shines. While the actual design of your Kanban board will need to be analyzed by your team, you can potentially start with a simple 2 swim-lane board that mirrors your current process for doing your work. A simple example is shown below -
Here, you have all your engineers available for working in either lanes. As work flows in, depending on who is free to take it up - and CAN take it up - they pull work in and work on it. You still batch things for the sprint at Staging - and deploy the batch at one go.
Alternately, you might have completely separate lanes for User Stories and Defects -
Here again, all your engineers work on items in both lanes. However, you have the flexibility to deploy defect fixes as soon as they are fixed and accepted by the customer (if applicable). With your value demand, you continue to follow the same process as you are now and deploy when each sprint is done.
The advantages of either of these approaches are -
You get a bigger pool of people to work on either situation.
You potentially get faster response times, better SLA performance, on defects.
You get a happier team where everyone gets to work on new stuff. Most engineers don't want to be 'maintenance' guys :-)
Of course, this is just based on basic analysis. If you are not familiar with Kanban or Scrumban, you should read books by David Anderson (Kanban) and papers by Corey Ladas (Scrumban) and several others like Yuval Yeret, Jim Benson, Masa Maeda and prepare yourself better. You can also connect with us at www.swiftkanban.com and we can certainly help as well.
Hope this helps!
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
Specifically, should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it? Thanks!
We use the time to fix bugs, and to pay back some technical debt.
If you can do this without talking to your product owner depends on your understanding of scrum or your work arrangement with the product owner.
In my personal opinion you make a promise for the sprint. Your part of the deal is to hold the promise. The Product Owner on the other hand is supposed to stay out of technical stuff, since that's what the developers are good at. Technical Debt is technical stuff. Bugs might be. But in the end you have to come to a common understanding with the PO what you can decide on your own and what you have to consult the PO with. In an ideal world the developers know so much about the product that they can make the decision on their own.
Starting on the next item is of course another option. If you can't finish it, Lex Scrum says don't touch it. And I like this law to some extend, because it actually creates slack that can be put to good use by developers ... like fixing bugs and paying back technical debt. If implementing another story is the best use of your time: find one that you can finish. If you can't find/create one, this is actually an impediment that you just found. Assuming we are talking at least about something like 4hours for 2-3 developers, we really should be able to find something useful to implement with these resources, shouldn't we?
should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it?
Remember "Individuals and interactions over processes and tools" Do what your common sense tells you. Do not get too caught up in tools and processes.
As per the Scrum guide, the amount of work the Team commits to is completely up to the Team.
There is no harm in starting a next highest priority item when all the items above it are done. What would be preferable though is break the item down into a smaller or thinner slice which can actually be done.
If the Team finishes all it's Backlog Items well ahead of time, the team should definitely take up a few more.
I would take the next highest item in the backlog and work with the product owner on creating a story that can can be completed in this iteration...so break the story into a smaller size to fit.
We haven't taken new work irrespective of whether it can be finished within the sprint or not. You should instead focus on Technical Debt, Design Debt, Code Debt
Definitely break the story into something that fits. The team should never be committing to something it can't finish in a sprint. Additionally, only the team can add new work. If the team finishes early, the team needs to work with the Product Owner and agree to add work to the sprint. I've seen teams get into trouble when the "lead" or even the Scrummaster starts negotiating with the Product Owner outside of the team.
To answer the question definitively, Scrum says that you should negotiate with the Product Owner and about taking in extra work.
Scrum done well has the Scrum Team review their progress every day so you should see an early finish predicted way before it actually happens, giving you enough time to chat with the Product Owner about what to bring in to the Sprint.
Scrum done well also has the Scrum Team prepare User Stories well in advance of being pulled in to a Sprint (via Sprint Planning and Product Backlog Refinement) so the need to break a User Story into smaller components so they can fit in to a Sprint is lessened considerably.
Either you can break a story into a smaller one so you can deal with it within the current sprint or you can have a story informally split into two sprints putting off some of its tasks to the next one.
Remember that agile comes down to finding the best way to fit your team's needs, not about following structured rules.
Whichever way you go, I'd simply go to the team and ask them what do they want or think they should do. Remember, in Scrum we value self managing teams.
For suggestions, if they're stumped, I would say do one of the following:
Reduce technical debt
Use the time to learn something valuable
Let the team take a "Gold Card". They're on time, they probably earned it.
Split the next story into smaller (though still meaningful) stories, the first of which can be completed in time for the end of the sprint.
If the next story can't be completed as above, take the next story that can be completed in time.
Hope this helps,
Assaf.
Here's what my teams do-
First, it's up to the team to decide what additional work that they can fit into the remaining part of the sprint. It's critical that the whole team votes on this, not just the developers.
Second, if the team decides that they can handle X more points of work then they go to the PO and confirm the priority of the backlog items and find one or more stories that sum up to that X points. Sometimes they have to move down the backlog a bit to find ones that will fit. As long as the PO is ok with the final selection, the team moves forward with the new work.
Third, whatever new work the team selects has the same commitment level as the original work. Any partially completed stories at the end of the sprint are failed.
Finally, during planning for the next sprint, the velocity is adjusted upward (in this case) because it's quite likely that the team under-selected work at the beginning. This is a crucial point - the velocity should always reflect the team's best guess based on recent past history as to their work capacity. If the PO sees that the team is finishing early and heading off to do other non-backlog work, this can cause trust problems between the PO and the team. It's perfectly fine to decide as a team along with the PO to focus on technical debt (although I think that these are still stories since the work needs to be tested) or other items as long as there is discussion and agreement.
I think this is something you'll need to take a view on after a number of sprints. If you're regularly left with spare time at the end of a sprint, you should probably commit to more work in the planning session.
If it is happening rarely, I'd caution against routinely adding in tasks from the backlog as a matter of course. Unless you've done some decent backlog grooming they're unlikely to be the quick-wins they first appear. You also want to avoid a protracted mini planning session as those days you have free could quickly trickle away - especially if you're including the views of developers who have tasks outstanding.
By all means, seek to get ahead for the next sprint by reducing technical debt or backlog grooming etc but putting yourself on the back foot by committing to work late on is rarely worth the effort.
I think a solution of an under-committed sprint could be to stop the sprint. If the team has done the work then the sprint is over. The other option of adding more stories into the sprint backlog is too risky, and rarely will a team be 100% sure they can handle all the extra work.
As far as I know there is no rule that a (let's say, 2-week) sprint cannot be ended 2 or 3 days early.
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 recently interviewed with a company which has started introducing Scrum for their development cycles. I asked one of the developers how their experience has been, and it sounds like they are completely divested from the planning process. He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Basically, at the start of the last Sprint (or two) he was handed a to-do list. He had to breakdown items into their respective tasks (so they could be worked on over the Sprint), but wasn't involved in any planning activities; I'm skeptical he was allowed much input into how much effort an item might take -- I suspect the architects decided this for the team.
Is this how Scrum should be handled? My current team fully participates in all planning activities, continually adding our input as to how features may be addressed and how much effort they might take. I'm a bit skeptical (and nervous) about a company which simply hands developers a to-do list without asking for their input.
Note: I understand that once a Sprint starts, the list really is a prioritized to-do list. My concern is not having input into the planning process from the start.
If those who are doing the work don't get to give input saying what amount of work can fit into a sprint and let the business decide whats most important and should be scheduled to fit. Its not going to work run away. They are using new trendy agile words but doing the same old things.
(...) He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Obviously, they're still doing command and control and micro-management (the team is not empowered and self-organizing) and they are still using push-based scheduling (they didn't enable pull-scheduling).
Scrum has other characteristics but the above points are more than enough to say that they aren't doing Scrum, regardless of how they name it, they didn't really shift from the outdated waterfall approach (they just did put some lipstick on the pig).
This is a big hint that they're still totally clueless about what Scrum is about, they didn't get it at all. And this is not going to change without some inspection and adaptation, if they even want to change. If you don't have the power to make this happen, run away.
Is this how Scrum should be handled?
No.
I worked at a place that called themselves agile. They had 6-8 month release cycles. Some things came from a backlog, but during the "Requirements Gathering" phase, basically the managers would spend a week or two meeting with various people in the company, and write up a feature list. The first day of each 4 week "iteration", the dev team would all get together and break down everything in a series of meetings. The last day of the iteration was deployment day, where there would be an intrim deployment that nobody outside of the dev team ever saw.
During the 8 month release cycle, the managers would touch base with the stakeholders maybe once or twice in the last two months of the release, at which point the only issues raised in those meetings that had a chance in hell of getting done before release were issues that were bad enough to make the whole effort useless if they were not implemented.
This is not agile, this is a variant on waterfall with a poor choice of ideas and methodologies cherry picked from other methodologies. At the end of the day, it still has all the same problems that waterfall does.
The lesson I took from my employment there is that development methodologies include things for a reason. If you are cherry picking from a methodology without fully understanding it (and by fully understanding, I mean having actually worked with it), there is a high chance that you will not use something that is actually vitally important to the whole thing. For example, in xp, kent beck advocates relying on refactoring later as a way to cut down on up front design. However, the only reason this actually works is that he also advocates TDD and pair programming. If you have a comprehensive test suite and an extra set of eyes there for the whole thing, refactoring is fairly safe. If you just cherry pick the first part and leave those two out, you are essentially cowboy coding.
I am extremely skeptical of shoppes that roll their own methodologies for this reason. There are an absolutely shocking amount of crimes being committed in the name of agile.
Is this how Scrum should be handled?
Definitely not. Scrum strives to increase transparency. By blocking developers from planning activities, they are doing the opposite of what scrum suggests.
You talked about 2 points here:
1. Sprint Planning - The Scrum Team members should be Definitely required here.
2. Backlog Grooming - May or may not be required here. You have to use your resources wisely and with common sense. One team member with strong developer background would be okay here I think.
There is one more type in Scrum:
Release Planning - Some might say developers are not needed here. But as per the Scrum Guide - "Release planning requires estimating and prioritizing the Product Backlog for the Release". Well prioritization can be done by the POs and suggested by the stake holders, but estimating would be most accurate if it is done by someone who is actually going to do the work, so it is a good idea to involve developers here. Again, resources should be used wisely. If it makes sense to not involve all developers and have people rotate turns to estimate, that is not a bad idea.
I suggest follow this structure:
Sprint Planning - part 1 : Estimation and pulling backlogs in Sprint from product backlog (PO, SM and Team are pigs here)
Sprint Planning - part 2 : Tasking, estimating task hours and breaking them down. (SM, and Team are pigs, PO is chicken here unless PO is taking tasks as well)
It is up to the team to figure out, during the sprint planning meeting, how it will turn the selected product backlog into a shippable product functionality. If they are not part of this process then they would not be able to commit.
The answer to your title question is: Developers (team) must participate in planning meetings. Planning meetings are for developers (team).
The good approach is to have two planning meetings at the beginning of each sprint: Planning meeting 1 and Planning meeting 2. In Planning meeting 1 Product owner gives prioritized (and size estimated - size estimation is not done on planning meeting) product backlog to the team and team starts to discuss most prioritized user stories. For each disucssed user story team should be able to collect:
Detailed requirements (for example which fields the input form has to have ...)
Constraints (for example how fast the functionality has to be)
Acceptance tests (verification of results)
UI sketches (for example how should UI flow looks like)
Acceptance criteria (validation from end user - acceptance criteria doesn't have to be real test. It can be something related to "easy to use" etc.)
There should be time boundary for Planning meeting 1. Number of user stories you were able to discuss can correspond to number of user stories you will be able to complete in upcoming sprint. At the end of Planning meeting 1 team must make commitment - say how many of discussed user stories will be done in upcomming sprint. Sprint planning meeting 2 is only for team because team further discusses user stories and breaks them into tasks.
Generally, of course they should. Obviously, it's never realistically possible to the degree that developers would like. However, if sprints are usually "Hair On Fire" type affairs, where the developers get no serious input at all... then at the very LEAST there should be regularly-scheduled "entropy reduction" sprints, where all tasks are selected exclusively by the developers for the purpose of cleaning crap up.
At least some developers need to be there so work can be properly estimated and pipelined.
But not all developers need to be there. All can be there is it makes more sense.
On the other hand, developers need to understand that the business priorities are the priorities, no matter what they think should come next. Everyone has to work together ot make it work.
I'm not so much worried about my input, but about my insight. I recently was involved in a project where I had no knowledge of the project before the plans were handed to me supposedly complete. The nightmare started when I discovered that the process was not completely thought out and the data definitions were not complete. I wound up having to go through the whole process again to get the answers that I required.
The Team can be involved in the planning process without a formal process or meeting. The planning process is really very fluid. At the start, the goal should be to get to starting sprints ASAP. Spending too much time in planning before the first sprint feels very waterfall and is a waste of everyone's time. I, as a team member would feel relieved to not be a part of that, except for the fact that it indicates a dysfunctional nature to the organization. The Team should always be free to voice ideas on an ongoing basis (since that's when the real planning happens). But, 2 things you mentioned concern me most.
First, the Team should be the only ones to determine how many backlog items they can do this sprint. They certainly would be involved in estimating the effort. That's a big problem.
Second, the Team does not sound like they have access to the product owner (maybe there ins't even one here). Even if the team has not been involved in the "planning" thus far, surely if I were talking to the product owner in the planning meeting, or had access to them at other times, I would voice suggestions over time.
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 in the process of developing an new product and implementing Agile, specifically Scrum. Our first sprint was planned conservatively, but we are going to miss our target by quite a bit. The main cause being interuptions and new clients throwing in last minute requirements that we had stop and react to.
To be able to help identify our weaknesses and also so I can get some fodder together for a retrospective of our first sprint, I am interested in hearing about companies developer head count versus user head count. Is your ratio/mix a successful one? Only for internal development, not software houses or tech companies. Any opinions on the subject are also welcomed, I think it could open an interesting discussion.
The main limiting factor is always budget, so there is no need to include that in any opinions.
Don't be too upset with failing your first sprint. It is rare to do anything 100% the first time. Most first sprints reveal problems that have to be fixed - just as it was in your case.
Your problem has nothing to do with the users / developers ratio. Your problem is properly insulating your sprints and making sure the basic Scrum deal (no scope changes mid-sprint, all scope changes between sprints) is adhered to. Things to do:
Make sure everyone understands Sprint Backlog can't be changed between Sprint Planning and Sprint Review. If anyone tries to force this play by the book: do abnormal termination, throw away all the work work, plan a new sprint and make all of the fuss about it. The reason Scrum calls for this is to make the cost of interruptions and scope changes highly, painfully visible.
Shorten your sprints. Two week sprints worked very well for us because it was pretty easy to explain to any manager type that he can wait 2-3 weeks for his feature. Our PO got pretty good at this eventually.
If for any reason you have short fixes / features that can't wait two weeks institute a "firefighter" - devote one developer per sprint to handling such issues, don't plan any regular work for him. To avoid burnout make it a rotating function - someone is the firefighter each sprint. Hey, you could even buy them a firefighter hat. :)
We did 1 & 2 after our first sprint (way back in 2007) blew just like yours. It helped a lot, so we didn't have to do 3. I advised 3 to a team that had such need and it worked pretty well.
If you allow new requirements during a sprint for this sprint, you're not doing scrum.
The only thing I would allow, are critical bugs in producitve software. These have to be fixed. Here one would allocate one or two devs per sprint who are responsible for bugfixing, if the need arises.
Too many users is not (should not be) a problem. The developer to user ratio depends on the type of the product and the industry/domain, not on the methodology. Small shrinkwrap products (developed by a minimal team, or even a single person) can have millions of users (e.g. Total Commander), while huge internal enterprise products developed by a team of hundreds can have half a dozen users.
The problem is rather that apparently your users are not familiar with Scrum, and you are not using a single product backlog (or haven't taught your users about it).
You should have a single product owner, who decides about what gets into the next sprint, at the start of the sprint. Last minute change requests are (ideally) not allowed - they can only get into the next sprint. It is the product owner's responsibility to communicate with the users, collect and evaluate feature ideas/requests, prioritize them, and OTOH communicate these towards the dev team. In other words, users should never ask features directly from individual developers; they should turn to the product owner instead.
The essence of scrum sprints is that you can't interrupt them with last minute requirements.
Regarding the ratio you are talking about, it depends greatly on what your product is, in which industry you are, and lot of things like that. So to make this value useful, you will have to experiment a bit.
But your developers should rely on your product owner, and not your user base (regardless its size).
Sprint is safe zone. At the beginning of the sprint team discusses product backlog items with product owner and selects subset of these items to be done in upcomming sprint. Team commits to these items. It is team responsibility to deliver commited items so no one can introduce new items during the sprint except the team (this usually happens when items are developed faster than was expected).
Each SCRUM project has to have one Product owner (if there is more than one, there has to be hiearchy) which is responsible for product backlog. If the product owner demands new items during sprint the only way to do it is to cancel current sprint and start the new one.
Possibly a more meaningful ratio would be developers : features/projects. If a manager commits all available resources to a sprint, then there is a higher probability that you'll need to interrupt at least one of them for a critical support issue (for instance); it's a slippery slope to things like "well, you're ahead of schedule, so can you slip this extra functionality in", at which point you've broken one of the core principles behind SCRUM.
I get the feeling you're about to start a campaign for more headcount in your department, to relieve pressures on the current team; perhaps a better long term approach would be to manage expectations of your customers (be they internal or external), so that your existing headcount remains flexible to jump in and handle interruptions; at the same time they can manage expectations that additional requirements get deferred to a later sprint.
developer head count versus user head count
I'll probably get downvoted for that but I think it is largely irrelevant.
There are fantastic products built by a couple of guys serving millions of users.
Just as there are projects developed by a huge strike force which never crossed the threshold of mediocrity.
User head count / dev head count is not a relevant metric.
You can have a single user that generates huge amounts of change versus hundreds that don't generate any (of very little) change.
What is relevant is the amount of change being requested and how it is managed and tracked.
If you can show how much the requirements have changed while still implementing and designing for other requirements you will have your fodder.
One of the biggest mis-conceptions about any Agile methodology is that you can make it up as you go along.
And although this generally true, the key thing is project management and communication.
Like a lot of things in life you can do anything, but there is a consequence. If I buy a Ferrari can I afford to eat?
If I ask for an extra bit of functionality how much is that going to affect the project.
So during planning
MoSCoW (Must, Should, Could or Wont) requirements
Estimate how long it will take
You cannot fill a Sprint / Timebox with Musts or Shoulds
During the sprint / timebox
Monitor the time it takes against Estimates
Re-plan
When an interruption occurs. Log it and feed this into the Time Taken requirement. Next set of estimates include and interruption factor. Estimation within Agile is an Artform!
When changes are asked for
Estimate how long it will take, compare with original estimate
Inform the Business User of the effect
Prioritise within the MoSCoW
Communication is important. If you want me to add that button there, I will not be able to print the invoice.
Because of MoSCoW it maybe that in sprint 4 the item which is a Wont might make it's way up to a Should or a Must.
Also treat Agile as a toolkit you do not need to prescribe to SCRUM or any other methodology pick the important bits which work for the culture you are in.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.
EDIT: Additional Information:
We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.
EDIT: More insight/confusion perhaps:
I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.
Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.
If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.
Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.
Take an interation to rework or bug squash. That should give the BAs sometime to get ahead of the curve.
If, however, the problem is that the BAs need to see the previous requirements in the "wild" before making more requirements you have much bigger issues. :)
At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.
Update to respond to the questioneers Update
It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"
Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.
I take it that there is no sprint planning sessions from what you say.
Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:
Apart from having short sprints that is.
Well, a couple of things might help
- In the SCRUM process, there is the concept of Product Owner wchich is a Pig Role, this represents the customer. So you can invite the PLM or the client's main contact to your SCRUM's meeting. This will give your customer's some buy-in into your process and will get them to work "with" you on your goals
- Weekly builds to the client might help. So, the basic idea of the weekly drops is to show the customer "progress". So if for a few weeks there is no progress, this should raise the question "why?" and then you should be able to explain that it is for the lack of requirements finalization.
Hope this helps
the "user story" is a placeholder for a future conversation, so get in front of the customer and ask them; if that's the BA's job, light a fire ;-)
Your user stories are incomplete. 'Customize X screen' is a task, it doesn't describe any requirements or completion criteria. The user story should be something like 'Allow Nancy to see the related purchase orders for an item in inventory'. Then break that down into tasks during your sprint that you can work on.
Once the BAs have developed a workable user story then add it to your product backlog, prioritize it, and plan your sprints for the top backlog items. The BAs should be developing user stories and adding to your backlog independent of your sprints, and thus not blocking you. During a sprint the tasks are completed and the user story does not change. After releasing the customer provides feedback which goes into the product backlog as more user stories.
I see a few ways to handle this:
Option 1, Under SCRUM, you should have a Product Owner who is managing your product backlog, which is supposed to contain requests for features of the software. If the feature consists of something vague like 'Customize screen X' and you decide to add that to your sprint, then the sprint tasks should be concrete, decomposed tasks, and I would say one of those tasks has to be 'Define requirements for screen X'.
During the daily SCRUM, when you're asking your three questions of each team member, the developer who has that screen mod task will say "I'm blocked waiting for requirements from the BA.", and your scrum master does what they can to get that moving along.
option 2, in my opinion, is that items do not go into your product backlog until they're defined well enough to do at least some productive work on. We all know requirements change, but the point is that you're supposed to have enough to start with.
Easy.
Allow yourself to think outside of Scrum's strict rules, and get back to your lean roots:
http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/
http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Trust me, once you get that flow going, you'll never look back.
As it is said above, usually at the beginning of each sprint you should prioritize the existing backlog and pick some stories for the current sprint. If there is not enough user stories for the developers, you should shift developers to another project and let the product owner some time to create a decent (=large enough to feed some team) backlog for the project.