As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Our team is going to adopt scrum and agile technics.
We've got a product, which we develop for multiple customers. This customers supplied us with necessary requirements, so everithing is fine to adopt agile techinics.
But at some moment (for example during sprint), new customer apears, and he wants to get a demo of product slightly different from what we have now. This may be some new features or minor differences in behavior. And he wants to get this demo for example during the week. It is very important to show that our product supports this features (because otherwise he will address to our competitors), so we have to develop this features (may be partly) during the week.
How we must handle this sort of features with agile? Move them to current sprint backlog? Or split one team to two and create another sprint? Or may be there is another way?
I generally agree with jessehouwing's answer. If the problem you outline is uncommon, then what he has answered makes sense. IF this will be a common occurrence, sprinting may not be the answer you are looking for. A more flexible approach to this problem would be Kanban. In Kanban you work story by story instead of planning an entire sprint. This style works nicely for teams who have regularly changing priorities.
Scrum allows you to re-negotiate the sprint between the Product Owner and the Development team, so if this item is very very important, the PO can propose the team to swap out already planned, but not started, work of the same size.
Or when the amount of work will consume all time remaining in the sprint, the PO can cancel the current sprint and call for a new sprint, with these changes as the most important items. All undone work in the cancelled sprint should be considered lost.
If these kinds of mid-sprint-changes happen frequently, you might want to reserve some capacity to accommodate these types of requests. Just reduce the number of story points you'll take on during the sprint planning meeting. Or, depending on your current sprint length, you might want to reduce the number of days in a sprint to a week or something, that way you'll reduce the risk when these types of changes are required.
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 am working in 2 scrums as a developer, and it is difficult get anything done - I wanted to ask if other people have had the same issue and what did they do to manage their work?
It does not seem an agile way to work at all.
The problem is one of commitment. As a team you commit to your peers at the sprint planning meeting and each daily scrum what you will all accomplish together. If you have another team, that undermines that commitment naturally, it also inflates your WIP and causes task switching and the additional overhead of the ceremonies for two teams.
Why are you on both teams? The usual answers are: domain knowledge, skill set, because we only have one QA (insert any discipline there), funding/allocation, etc.
I fundamentally believe that your team will not have a reliable, predictable team until you form your teams in a way that you can commit to your team mates.
Report your situation as an impediment to the scrum master(s) and commit yourself only to the work you think you can achieve until this impediment is solved (by the scrum master(s)). It is not a contest on who commits to the most work done and then not achieving it.
I rather think this is a discipline issue. If you are following you need have scrum disciplines. What happens is when you are a shared resource, there will be switching cost and productivity loss. If you still want to follow this, you need to take actions to reduce switching cost and increase productivity.
One thing that you can defined dates where you are going to work on. Ex: first three days you are in one project and next two days your are in other project. If you define like that, then you can plan work to increase productivity and reduce switching cost.
Another thing is that reduce the participation time on stand ups and sprint planning. Make sure to prioritize your areas and discuss and then you leave those ceremonies than staying for the entire meeting. this is a responsibility of the scrum master to plan.
Working in multiple teams is possible, but each team needs to be considerate and accept they are only going to get 50% (or just under) of your time.
When planning, don't over commit, look at how many story points you can roughly achieve in a sprint and only commit to 50% of that total for each team.
Try splitting your time into Team A's work in the morning and Team B's in the afternoon. Each team will then know when you are available to them and should try (unless urgent) not to disturb you when you are not doing their work.
Have dedicated times for planning, standups and try to get the team to stick to these so you are not double booked.
The scrum master (or any elected person) for each team could also consider having a scrum of scrums where they get together and quickly discuss how things are going in the same way as a normal scrum so that they understand what pressures you are under.
However you mange this, you will get less actual work done than being in one team due to the commitments such as planning, standups, retrospectives which agile introduces.
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.
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 do you defines as an impediment? I know that Scrum say that and impediment is something that stop the team from performing the best it can. So basically it can be everything? But where goes the magical line where it becomes and internal improvement?
For example. We want to have more realistic test data in our databases, is that internal improvement or impediment? We as a team could try to solve it in the sprint along with the other stories directly, or we could say that it's an internal improvement that needs to be a story and go into the product backlog.
As I see it we have three options:
1. Handle all internal improvements as stories in the backlog and make the PO prioritize them.
2. Work with them along regular stories in the sprint.
3. Big things goes in as stories and small stuffs we can do directly in the sprint without it effecting the velocity much.
How do you handle this? We need tips and ideas on how we can do this :)
What is an Impediment
An impediment is anything holding the team back. It's a very wide open category that can include things like:
physical hardware limitations
missing or poor tools
personal conflicts
missing skills on the team
missing personal skills
lack of influence or authority
illness
missing knowledge
We often focus on the obvious: tools and authority, but more often it's the intangible that holds a team back. Things like team cohesiveness, knowledge, and experience.
More realistic test data
Don't get caught up categorizing the improvement as internal vs impediment. Our goal is to embed improvement into the natural delivery process. For that reason, my first inclination would be to say all impediments and improvements should be done in the context of delivering. You want improvement to be reflected in the ability to deliver. We want our outcomes to reflect reality. Sometimes improvement efforts mean we temporarily lower velocity in the name of future increases. Sometimes we even permanently lower velocity in the name of quality.
I would suggest finding incremental ways you can get to your proposed end state and implement a little bit of it each time you touch that area, each sprint, and/or each time your prepare another test run (assuming it takes prep time - if not - fantastic!).
Improvements on Backlog
This is your choice and something you should discuss with your PO. Understand that while the PO wants high quality and improved output from sprints, the backlog is meant to represent valuable features/requirements from the user's perspective - not yours. For that reason, I would be hesitent to put improvement items on the backlog. You should ALWAYS be improving with each backlog item. Your PO may also balk at filling the backlog with things they feel should be done as part of normal delivery. Take it as a signal that this stuff is not directly valuable to the user, but a cost of delivering high quality value at a sustainable pace.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases.
Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.
Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.
Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.
Again, for more details on how to do this read the referenced book.
Big Upfront Estimation is just Big Upfront Design with $$$ attached
You don't, that would go completely against the entire paradigm of agile.
Agile can be about Fixed Costs
What you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.
The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.
Short Sprints with customer feedback and approvals
Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.
Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.
So, you actually shouldn't do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.
Agile doesn't work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.
Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.
Set some very low goals, perhaps only two or three features.
Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.
The client benefits in the following ways:
Lower upfront cost (only a fraction of the total price). If things go tits up there is a limit on their financial exposure (sensible given that most software projects fail).
Have working software within a couple of months that may immediately solve some of their problems
Have working software to provoke thought/conversation about requirements
Client will discover more about what they actually want
Client gets to see how well you work. If they don't like it they can look elsewhere.
"you don't, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates).
You can't expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.
If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).
If the team haven't worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.
Let's suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).
The advantage of this approach is that you can measure the team's actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team's velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.
Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We have been trying Scrum but for a while now and are trying to formalize it within as our own version of Agile Application Development. Here's how our current process works. There are two main drawbacks to it as it stands right now. Wanted to get input on whether you have a similar approach and if the community has any practical tips for the impediments we currently have.
Scrum team = 4 Developers, 2 QA, 1 Tech Writer, 1 PO(PM), 1 Scrum Master (Engg Dir)
Release = 3 Sprints
Sprint = 2 weeks
PO and customers create product backlog of user stories and related acceptance criteria.
1 week Sprint planning at the start of each iteration
Day 1# Estimate the Sprint backlog and agree on priority
Day 2-5# Scrum team discuss stories and work on the details of each story in the Sprint backlog (get the details on the story, process flows if any, identify UE guidelines to apply, details for UI items/fields/widgets and their behavior if anything specific is required, understand acceptance criteria and create tests)
2 week Sprint with 15 min daily scrum
Repeat 3 week cycle
The two major drawbacks we're having in this are:
The details that are discussed in the spring planning week are not captured effectively and get noted on a wiki. Since there is no standard format for capturing such details in Scrum, often time is wasted in daily scrum or subsequent meetings are required to further understand story details. Whats the best way of capturing story details for a functionally fairly complex product in sprint planning? Most of the issues seem to be around UI and developers inability to decide how screens/fields should be laid out without detailed mocks.
How do you anticipate critical showstopper bugs that come back from customers when team is in a sprint cycle. Currently the Dev folks have to be pulled away into supporting these Red Account issues that crop up thus disrupting the sprint.
Any inputs on how we can improve this?
There is no "standard" Agile plan. Plans aren't important.. planning is. What i mean by that is adapt your plan regularly to reflect ground realities. Formulating a plan, having it blessed by the powers to be and then strapping on developers hasn't worked traditionally.
Sprint planning shouldn't go over a day if I'm not mistaken. One of the key ideas of scrum is that you don't spend too much time planning. If they do, stop and reconvene when you have better clarity.. dont trudge on.
Get prioritized set of stories from customer ~3 hrs
developers huddle to estimate ~3 hrs
show estimates and let customers change their bucket to reflect business needs (within sprint quota) ~rem time.
Documenting decisions:
Get a good scribe? Someone who can type away as fast as 4 people talk.. get the core statements/decisions in a high-visibility area like a chart.. or a wiki.. whatever works for you
UX Study:
Try to pipeline UX work. Make sure the UX people have already worked UI Details,Mock screens, workflows, etc. by the time the devs get to it. UX is working on stories for Iteration n+1 when the devs are working on iteration n. A bit difficult but can be done if UX is causing a lot of "thrashing" for you.
Bug-Duty:
One approach is to make all bugs as regular backlog items for the next iteration. Get Customer buy-in on which ones need to go in during sprint planning.
If that is not feasible, Trend bug-inflows, rate of fixing and plan for it. Keep x days marked away for the fix-on-demand devs dedicated for these requests.
Scope for improvement:
You need a dedicated person in the "customer" role (or coach/BA who can front for the customer) that the developers can get in touch with on a real-time basis. Daily scrum meetings should be timeboxed to 30 mins and shouldn't include story "clarifications". Stick to the 3 questions - What did you do yesterday? What are you doing today? Any obstacles you need help with?
The dev or sub-team in charge of a specific story should work with the Customer/Front in case of doubts while they are working on the specific task. They are responsible for extracting out the details as part of the development effort. They can request for help from other devs who have worked in related areas too if that helps. Work together with the customer to stay on the right track.
HTH
Yep. I noted that nowhere in your process were the developers listening / talking to the actual end users. This is a recipe for failure. You cannot expect your "PO" to catch all the nuances that the actual users will express.
Developers must talk to the end users. The PO should be there as well, to document what was discovered. This is the biggest problem I see in most development projects, separation of developers from users.
Why are you sprint planning meetings a week long? The goal of sprint planning is to get just enough detail to feel comfortable as a team with the features you can get done and commit to doing them. This usually takes less than a day (~4 hours). The actual implementation details are discovered just in time by the devs during the sprint. That is why it is so important that they have access to the PO and the users. If you are asking where to capture the details, then you are designing to much in the planning meeting. The details should go directly into code during the sprint as they are worked out.
What would be a showstopper? The PO sees the progress at the end of each sprint (2 weeks) and then decides if the business value is enough to warrant a release. If there were any critical issues then the PO would probably not release that sprint. Hopefully you can get your PO and maybe users to look at the product on a daily basis as features are completed and thus reduce the probability of issues at the end of a sprint.