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
All the documentation I've read explains in great detail how at the end of a Scrum sprint, tasks are complete, user stories are implemented, and a customer gets a demo and accepts the implementation.
What I'm unclear about is what happens when this goes wrong.
I understand that sprints are timeboxed, so you can't extend the sprint to make time to finish something. Especially when a team of newcomers to Scrum are estimating, they're likely underestimate the size of tasks. How do we deal with a task (and therefore a user story) that is incomplete when the sprint ends?
How do we deal with tasks / user stories that are abandoned; the team discovers as they embark on the work that it does not have value?
How do we deal with tasks that are thought complete, but that the customer can't accept?
I think I can imagine ad-hoc approaches to these situations when you're working with index cards (shrug your shoulders, and plan the next sprint), but what do you do in Rally (or similar) where the software forces structure upon you?
If a User Story isn't finished at the end of the sprint, then you move it to the next sprint.
If you discover, that a User Story has no value, DURING A SPRINT, then you should ask the product owner and/or scrum master, why it is even in the sprint. But if it happens, you close the story and the tasks and you may add other items to the current sprint.
If the customer doesn't accept the product of the User Story, then you have to check why he doesn't accept it. Either the acceptance criteria of the User Story is not fulfilled, in this case the User Story gets reopend and a Bug or an additional Task gets added to it. It may also be possible, that the acceptance criteria is fulfilled, but the customer has additional wishes, then a new user story has to be created and planned for the next sprints.
What I've always done is move unfinished stories to the next Sprint.
A possibility is that a story can be broken up into two logical pieces where one is finished and the other one isn't; in that case, you split up the story and put the unfinished piece(s) in the next Sprint.
For each incomplete user story, you'll want to use the Split option to disperse the remaining work into the next iteration (or backlog).
When you split a user story, the result is an unfinished user story in the past iteration (as a historical placeholder) and a continuation of the user story in the next iteration.
for more details: https://help.rallydev.com/manage-unfinished-work
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How do you deliver Potentially Shippable Code at the conclusion of each sprint when the broader project spans multiple sprints?
As Sklivvz said, your question is not very clear, but you mention in one of the comments:
However, if a project comprises of multiple stories that only make sense as a unit and are too numerous to deliver across a single sprint, then how does that work?
Stories should follow INVEST.
The I in INVEST stands for Independent which means that your stories should not have dependencies between sprints. You should break them down smaller enough so that they can be developed within a sprint.
Potentially Shippable, does not mean you have to ship, but the product owner can always have the choice to ship. For example, if the product you are developing does not meet the features of a Minimum Viable Product then your product manager might not want to ship. However, it is better to release early (and often) so that users can give feedback about the features. Perhaps the initial set of users are internal to your company or from friendly customer.
It's not clear to me why not!
The idea of agile is that your project has variable scope but pre-determined timings. So you time box everything and make sure that at each time box things are either finished or excluded.
In this sense, you have shippable code at every time box boundary (iteration). If your units of work (stories) span multiple boxes, then your team will make no progress until they can ship any unit. Of course, for this precise reason your stories need to be as small as possible.
A project can run for any number of iterations, until there's valuable things to do.
In other words, an agile project must have variable scope and by definition it should be possible to wrap it up at every iteration.
It can be delivered by being deployed on staging environments for customers to play with, or it can be delivered by being packaged into an installer which allows for it to be deployed on any location desired.
It would need to include any changes needed in such environments - such as new config files, db schema changes etc. These should be bundled as part of the deploy package (as manual steps, or better automated steps).
Of course - there is no one answer. Determine with the other members of your team (remember that this includes DEV, QA, Business and 'Customers') in this project what it means to deliver this /Potentially Shippable Code/ to your team. Then deliver it that way. Then discuss how that worked out. Then improve upon it.
Do time-boxed experiments, reflect on what happened, adapt/improve and determine another experiment. That is, IMNSHO, 'Agile'.
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 6 years ago.
Improve this question
In our team we are evaluating to use the kanban board as an organization tool for software development. The development phase will take about 6 months with a team of 5.
We have as input all the functional requirements agreed with the client, business rules and use cases - in other words, macroscopic requirements. We will convert these rules in stories to be "atomic" process units for the kanban board. The kanban itself will be used as a performance evaluation tool and progress roadmap.
The Kanban "prescribes" to have a fixed amount of stories for each stage, but as the software is new and complex, the "stories" will be probably some hundreds - so I guess that putting all the stories in the backlog at the beginning of the development wouldn't be a smart move.
What would it be the best practice for this case?
First, few teams set limits for backlog. Kanban advises work in progress (WIP) limits. Items in backlog are rarely considered "in progress."
Second, considering you, more or less, know the scope of the project it wouldn't make much sense of forcing yourself to artificially limit number of items in backlog.
At the same time you're right that putting a few hundreds items in backlog makes no sense. The board would be overcrowded and its usefulness would drop significantly.
Typical strategies to organize backlog is such cases include:
Keeping epic stories/features in backlog and splitting them into detailed stories/tasks only when you start working in them. This way you have far fewer items, while you're still able to deal with detailed tasks on development stages.
Stacking stories which are going to be a part of the same part of an app. If you already split your scope, there's no point in artificially hiding this information. You can, however, stack work items that are connected or will be done at the same time. It makes backlog cleaner and, once you start building the items, you can unstack them totally easy.
Staging backlog. If you have a rough plan how your development will be going you can have a couple of stages of your backlog. Early one which is a box where you store all the features you will build (it can be even a physical box attached to the board) and later one which shows only work for the very next time period. This way you see fewer items on the board, yet still, technically all the work is there.
Of course mixing all these ideas is possible, and even encouraged, whenever it seems reasonable.
BTW: You can see visualization of a couple of these techniques in this presentation (slide 21).
I must disagree: limits in backlog is a possibility. Probably not in the input column, but for instance if process has some prioritization columns, highest priority column can contain a limit thus saying that one may not push to many high priority tasks, because WIP cannot maintain such pace and they will be hanging dead there.
Kanban board looks like this
Henrik Kniberg in his free book about Kanban describes how setting WIP limit to backlog helps focus on most important functionality first.
I think this is good strategy especially for product owner. Backlog contains only stories to be developed in upcoming period while other stories might be in mind map or 'wishlist'.
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 10 years ago.
Improve this question
Are there any formal/informal measures of comparing completed functionality vs initial requirements of a project. Specifically, my goal is to identify any missed requirements early on in a project. Having gone through many agile/scrum methodology articles and books, one way to do this would be a requirements review during a "sprint review" but I was wondering if there were any other techniques/tools out there.
Thanks,
Are there any formal/informal measures of comparing completed functionality vs initial requirements of a project.
The word(s) you are looking for is "Done Criteria". It has a more deeper meaning than the words itself, in the Agile world. It is often the first thing to be fixed in an Agile Organization, if it is found to be missing. Below (at the end) is a link to an article which explains it in more detail.
Most Agile Teams use User Stories as their "initial requirements". The user story would be your initial requirements which would be just enough to get the Team started. The measure used, should be what most Teams call, "the Done Criteria". Every User story should have a done criteria. For eg. In order to call a backlog done, these list of things need to be Done. While setting this we do not worry about How it would be done, only What needs to be done.
During the Sprint Review, the Team would do a show and tell of the working software, and if it meets the done criteria, the PO should approve it to be officially marked done.
Off course, sometimes User stories have changing Done criteria, especially for new Teams or Projects, but that is perfectly normal, because a sign of a good user story is that it is negotiable. The Done Criteria can be slightly modified after getting approval of Team. Teams rarely disapprove these, unless the change causes a dramatic increase in complexity of the work to be done.
So to summarize:
Initial requirements i.e. User Stories need to have a "what" needs to be Done Criteria". If something is missed and discovered during the Sprint the PO may change the Done Criteria of a User Story after getting an approval from the Team.
During Sprint Reviews the working software can be measured against the Done Criteria, and if it measures up, the User Story can be called done.
http://scrumalliance.org/articles/105-what-is-definition-of-done-dod
In an agile approach, changes in requirements are expected and considered healthy. Responsiveness to change is considered more important than following a plan.
A sprint review is one place to gather feedback and new requirements. Usability tests also help. But what helps the most is heavy use of the software by a QA team and/or actual users.
If you happened to be using JIRA and GreenHopper for managing your requirements (as stories), you might find helpful a search for stories created after a certain date. Finding modified requirements would be more interesting.
Is software ever complete? Obviously the real benchmark for completeness is someone's mind's eye view of what the software should do.
Trying to measure against a person's mental image is ultimately going to be challenging and no formal method will ever really do it well. The only thing you can measure against are the requirements they give you. You can look at un-addressed requirements, but you can never measure the gap of what they didn't tell you.
The message I have gotten from the agile school of thought is that measuring completeness is kind of a waste of time - it's really the wrong question.
For example, with scrum, you make a prioritized backlog of all the requirements and just start working down the list. When the money/desire runs out... you stop.
If you're going the agile/scrum route as you imply, then generally you'll want to break up the project into small discrete units of effort. A project contains epics (or is an epic), an epic contains stories, a story contains tasks. (A task should ideally be 4-8 hours of work. Something that somebody can do in a work day.)
As each story is completed, it should be tested and verified. This generally isn't done for tasks because often a single task can't be tested by a user until other tasks for the story are complete. A user can't be expected to test "Write a method to persist an order to the database" but would instead test "When this button is clicked, the order is persisted to the database and the user is shown an updated shopping cart to include re-calculated taxes and shipping."
This testing/verification is not done by the developer. It should be verified by whoever is in charge of the product/project or a delegate thereof. The developer will naturally test it the way he or she wrote it, expecting it to work that way. If anything was misinterpreted in the requirements, it would just be misinterpreted again.
As each story is verified as complete, it's a discrete and measurable step towards project completion. (Measurable by how many tasks it involved and therefore how much work was completed towards the sum total.)
Keep in mind that any such measurements can change from one sprint to the next. If upper management is looking for a single road-map with completable steps along the way all the way to the end of the project, they may be misunderstanding a fundamental concept in agile development. The stories further down the line haven't been fully defined yet. They may involve more or less work than originally estimated, based on development done on (and changes made to) the immediate stories.
One way to try to approach the concept of fluid stories and changing requirements is to not think in terms of "projects" but just epics and stories. These discrete units should be wholly workable and testable on their own (though some will of course have others as pre-requisites). Changing priorities can move the stories around at will. A "project" doesn't need to be "put on hold" if priorities change, its stories are simply moved to the backlog in lieu of other stories.
The idea is that management is steering where you go next, not just giving you a list of destinations and hoping you'll arrive at them in the right order.
In this sense, the "completeness" of a "project" almost entirely loses its meaning. How much is "complete" is up to whoever owns the product/project. They can add to it or remove from it at will, shift priorities easily, etc. If they want to know "when will we arrive at destination A?" then that's up to them. You've given them estimates on how much work is involved in each step along the way, it's up to them to steer in what they think is the best direction to get there while you provide the work.
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
would like to explore what are the general practices in
dropping features
make a decision to delay the project schedule
design the features in a way that can be dropped with lesser pain
delay a project schedule with good estimation without re-delay again
preparation for project completion to avoid delay in schedule
Please note that it is not a question on schedule planning or management but more focus to time frame close to project completion.
I understand this is a question with no absolute answer.
If you get to this point and you don't have a plan, you're already in over your head. Most likely people are getting panicked and worked up and probably not thinking straight. That's also why people do fire drills. So that if the time comes to do it, they already have the process in place.
In this case, as soon as you start a phase of the project, you should have a prioritized feature/bug list in place. And then there should be two cutoffs to the list. The first one is the bottom of the list and includes everything. The second one is the minimum allowable for that deadline/release. And yes, they should be different. Think of them as the "must have" and the "nice to have" list.
Now that you have everything prioritized and you've set expectations that "if things run late, we start dropping things from the bottom", you'll have a much easier time in doing so if you have to. And of course, just because you drop it for the immediate deadline, doesn't mean you have to wait until the next big delivery for it... maybe a point release or an interim delivery is acceptable?
Or maybe the things that were dropped aren't all that important anyway? If that's the case, they may always stay at the bottom of the list and you may never get to them.
All of that said, it doesn't necessarily hurt to try to delay the date as long as you deliver what you have to. You can always ask and lay out your case and see what happens.
From the business perspective, you might have none, some or all of the above options available, e.g. if your contract says "by date X or you get no money", than you can only try adding resources or cutting requirements. Since you're close to project completion, adding more resources might be counter-productive.
Contract constraints aside, if you want to limit the scope, you should identify dependencies between features and have them prioritized by the user. It should go without saying that you do nothing unilaterally: whatever you do, make sure the customer is on board, even if he/she/they are not pleased by the situation (which is likely to be the case).
Delaying the delivery date is what happens most of the time: the best you can do is to react as soon as possible and keep the customer's expectations realistic. While this is painful, the customer is likely to appreciate the fact that he/she/they can adapt their own plans and avoid damage propagation (cancel or delay marketing plans etc.).
Estimates deserve to be mentioned separately. Estimates should have been available at every stage of the project. If you are not going to be on time, it is because you've spent more time than planned on completed tasks, because you feel the remaining tasks are more complex than anticipated or both. Update your estimates and let the customer know: use them to support your new proposed deadline. Including free support or an unplanned feature or two to make up for the delay might be easier to bear than transferring money, if the option is available.
It's a big subject: this just skims it.
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 6 years ago.
Improve this question
I new to Scrum and while I understand the team concept behind the Sprints, I imagine there still needs to be a guardian for the team who minimizes the interference from Product Owners who are not conversant in software development. What are your successes, and what horror stories have you lived through?
Update:
I am looking for the balance between coding to implement business process vs creating the appropriate architecture for a client. If the product owner is from the business unit there has to be guidance as to what amount of time should be spent on data model, etc.
Definition:
By "out of control" product owner I mean typically some one from the business unit who aggressively sets time frames while having no real technical ability to create that estimate. Typically this person will say: "I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."
Great answers everyone. Thanks for the good input.
The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.
So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.
Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.
"there has to be guidance as to what amount of time should be spent on data model, etc."
Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.
What can get out of control?
Redefining the work before anything gets done?
Redefining the priorities before the work gets done?
The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.
If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.
The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.
The product owner must not give the estimates.
I don't think it's a question of "out of control".
"I need those screens before the next
meeting with the Operating Committee
next week, so prioritize those work
products first. We'll tackle the
database after we talk to Operations."
There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:
The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.
The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.
Ultimately, your SM is the one in charge of enforcing process. They should act like it.
I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.
Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.
If you want a more specific answer, you need to define what you mean by an "out of control" product owner.
I have two things to say.
You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).
This guy can and should (I think) "protect" developers.
We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.
Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well.
Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.
The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".
But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..
We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all).
For this case R&D manager - a very good idea too..
Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)
I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.
Make sure that all your user
stories are well defined and that
the owner in agreement with them.
Once a sprint has started, insist
that new tasks cannot be added to
the current sprint, but they can be
high priority in the next sprint.
Shorter sprints make this much
easier.
Also, in order to remove the
imposition of artificial deadlines,
you really shouldn't deliver items
from the current sprint until the
beginning of the next sprint when
possible.
The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.
The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.
The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.
Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started.
This should be the exception, not the rule.
Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.
An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.
Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.
i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:
Key Elements :
Divide into the sub-user story based on stack track
Estimate each user story related to this
Scrum master should Informed the Product Owner about the timeline
to finish this user story based on team current team velocity
Product owner should be mature enough to understand the timeline as it
can't be completed within the sprint.
If Still PO has the problem for priority ,He/she can consult the
Scrum Master/Coach.
At a glance, Agile is more for helping business but need to take care that
it won't overload scrum team . As it is a regular process for
iterative development.