Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 hours ago.
Improve this question
Sprint planning has completed, sprint goals set, all is well. 2 days in the PO asks the lead developer if they could add a new item into the sprint, "it's an easy fix" "another team wants this".
What should the developer and the Scrum Master do? What is the conversation?
The Scrum Master may have a conversation with the Product Owner to understand the workflow on how an item comes into a Sprint backlog. If the Product Owner understands the workflow eg: Create item, Item satisfies "Definition of Ready" (User story template, estimate...), Item lands in Backlog, Item may be pulled in Sprint Backlog if there is free capacity and it does not affect any Sprint Goal.
The Scrum Master can plan ahead for this in multiple ways:
Plan less story points to the sprints in case this happens again, leaving room to add some extra ad-hocs tickets when they come
Take out a ticket from the current sprint with the same amount of story points that the ticket the PO is trying to add
Help the POs reflect and ask them: "what happen if we don't do this ad-hoc right now?" "Adding this ticket to the on going sprint will aid or delay the progress towards the sprint goal?"
Alternatively, manage expectations by creating a list together with the lead dev and the PO with a set of rules about when it is ok to add a ticket to an on going sprint, so everybody is on the same page
Scrum has always accounted for this situation from the very beginning. The simple answer is that the Sprint Backlog is "locked down" at the start of the Sprint and cannot be changed. This, "Oh, it's just a quick fix." situation was exactly described by Ken in the original book as a prime source of distractions that get in the way of the Team from succeeding.
There's only one recourse, which is a "premature termination of the Sprint". The Sprint ends immediately, nothing is delivered and a new Sprint is started with a new Sprint Backlog and a new end date.
It sounds harsh, but the truth is that the organization won't respect the Team's time unless you say "No" in these situations.
Another aspect to this is that someone early on, I cannot remember who, said the Sprint length should be set to the length of time that the organization go without changing its mind. So if this is a real problem, then shorten up the Sprints.
Back at the beginning, most teams used 4 week Sprints, and this is now seen as way too long. If you can swing it, a 1 week Sprint can be way better. In the example given in the question, 2 days into the Sprint is 3 days away from the end of a 1 week Sprint, and waiting for the next Sprint for the "quick win" is probably going to be fine.
The answer to most Scrum problems is often to make your stuff smaller.
What should the SM do? Well... nothing.
If the SM has coached the team properly, and they understand that they have committed to the Sprint Goal and understand it cannot be endangered, then you can just assume that the person being asked to do the work feels confident that the extra task and the Sprint Goal can be met.
If the extra task is competed and the Sprint Goal is failed, then that's a learning exercise for the Retro - Does everyone in the team understand that the Sprint Goal is a commitment and that it shouldn't be endangered? You could also cover techniques for helping the team handle such situations.
There's nothing wrong with the team doing extra tasks - as long as the Sprint Goal is met. This covers the self-management part of Scrum. The team decide for themselves if they are capable enough to do both activities in the Sprint timebox, and if not, they need to be coached to push back.
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 1 year ago.
Improve this question
I am new to scrum , I would be happy if you tell me as a scrum master what should I do in a backlog grooming session and when sprint planning happens exactly and how we estimate the amount of time that we need for each item in the backlog and what planning poker estimates exactly.
It's definitely worth looking at the Scrum Guide for some guidance, though that certainly leaves a lot of room for interpretation. For sprint planning, there are three parts, noted here: https://scrumguides.org/scrum-guide.html#sprint-planning
You're going to want to establish a preliminary sprint goal (the guide notes that it doesn't have to be finalized until the end of planning), then identify which backlog items need to come in to meet that sprint goal, and finally, put together a preliminary plan on how the work will be done. Of course, this is all collaborative. Generally speaking, the PO focuses on the most important work being done first to deliver the most value and the developers focus on what's a reasonable workload and how doing different tasks together may be more effective than others.
Refinement is purposefully vague. It's whatever conversation need to happen to make upcoming Sprint Plannings successful.
Planning poker is a rather broad topic - it is simply a technique for relative estimation. These sizes represent the overall size of an item relative to others. This is not a direct translation to time. Rather, there is a correlation when discussing similar work with a similar team. A great analogy from Mike Cohn is with distance running. A 10k is one size bigger than a 5k, but it doesn't tell us how long a given runner would take and you can't assume that any given runner will take twice as long to run a 10k as they do to run a 5k (or any other clear ratio). However, once someone runs a number of these, you can start making rough time estimates about how long it will take that runner to run similar courses.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. Scrum master helps the Scrum Team understand the need for clear and concise Product Backlog items.
It should be done before Sprint planning and the team should do it frequent basis. In backlog refinement, the Scrum team discusses/refine stories. If possible then assign story points as well(Size estimation, could be t-shirt sizing or story pointing). Story points are provided by taking some small stories as a base story and by comparison we can give story points. Or we can give story points based on work that needs to be done and the efforts it will require. Before starting with the story pointing team should agree on some mutual measuring unit(Can take a story as a base, Required Efforts, many more ways). Usually, it's kind of a rough estimation. It's good if you have some field in your tool to make stories as ready/draft/purposed...
The scrum master needs to ensure this session should happen and facilitate the same.
In Planning, Majorly team decides what can be achieved in a sprint. Value of the sprint and plan on how we will be achieving the targets. The team sits together and takeup stories from the refined backlog. Before starting taking up stories team should calculate team capacity by capacity planning. Usually, the team should take up stories that are in a ready state(Means already discussed). Scrum Master facilitate this event. Usually, planning is done by the scrum development team.
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
When and who undertakes the work to sufficiently gather answers so that we can start to write stories for an upcoming sprint. Is this work done continuously and in parallel to existing sprints by the product owner? I guess this then creates tasks for a sprint such as investigate x and y. What if the PO suddenly requires a developer to answer some of the questions by trying stuff out? I understand the idea of spiking and creating r & d tasks. I guess I want to avoid the main dev of a feature being delayed to a following sprint too often.
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.
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
So we start Scrum today and start going over story points estimates.
The first story that comes up is a new screen that needs to be developed. It has 1 sentence to describe the screen and 3 user acceptance tests.
This starts a fight between the development team and the product owner.
Product owner says that stories do not need to be speced out and they will just be fleshed out during the sprint.
We say that the story needs to be completely speced out for the sprint.
But now I am starting to be unsure about who is right....
Any good articles on this that I can send to the team about how defined a user story has to be?
What happened during sprint planning?
It appears that you did not review the sprint plan to see the stories in advance of starting the sprint.
That's okay.
Stories are fleshed out during the sprint. That's the point. Relax.
Flesh out the story quickly, build quickly.
At some point, the one sentence story may become rather complex. If that's the case, break it up into something you will finish during the sprint, and stuff you will not finish. It's okay to have some stuff that was not known and did not get built.
Relax.
Do not overspecify everything. Do not specify every nuance of the story before the sprint. Just build something that will work. As quickly as possible. That's why it's called a "sprint".
Don't build everything you imagine. Build enough that the story can be performed by the user.
The point is to build something that works on schedule. If you have to adjust the scope of the story, that's okay.
Any good articles on this that I can send to the team about how defined a user story has to be?
A story is typically made of one sentence based on the following template: In order to <benefits>, as a <role> I want <action> (and I like to add "how to demo" steps that help to understand the story and to build acceptance tests). The idea is to capture the essence, not the details. Details are captured using face to face conversation during the sprint (and may be added as high level notes to the story). But a user story is not a contract, it's a promise for a conversation (about the scenario for which the story is the title). If you need some guidelines, following the INVEST model has worked well for us.
PS: No offense but the development team seems to react very defensively (asking for full speced things sounds like "hey, we did it as it is written", i.e. CYA). A user story leaves some space for creativity. Isn't that nice? If you need more details, take your responsibilities, go gather them. And if for any reason you can't get required clarifications or details, raise an impediment and have your ScrumMaster work on it. Personally, I enjoy having some space for creativity.
IMHO fighting is not good - Product Owner, Scrum Master and Development Team form the Scrum Team so they need to work together. They want to achieve the same thing - building a great product.
To me the question is how important it is for the Product Owner how the end result looks like. If he says: "We hired the best people on the market, you're the experts, whatever you come up with is fine with me as long as the user need is fulfilled", then I'd fine with the PO statement. But of course he can not complain afterwards that he does not like the look or the colors!
Another point is that the team needs to be confident that they can commit to this story. Usually teams estimate story size with planing poker so if the development team can not estimate, you need to invest time before that you can estimate (e.g. talking about the story before, spiking and negotiate with the PO about the story). Sometimes the designer/UX guy needs to work ahead and create mockups for the upcoming user stories.
It's always about finding the balance between planning and doing :-)
fs
I believe Martin Fowler's blog post on Conversational Stories probably answers your question best. You really don't want to be in a situation where the Product Owner is required to spec out everything in detail. You've got a team of smart, creative people that are perfectly capable of making good implementation suggestions as well as asking the right questions as they come up during the sprint. You don't want to lose out on that creativity and input by locking down requirements up front.
The story should be clear enough that the team understands what the feature is and small enough that the team can complete it in one sprint before it is added to the sprint backlog. The rest of the details should be handled via conversations during the sprint.
In our practice we do internal investigation of tickets for the next spring before planing with stakeholders. We usually find a lot of questions to clarify. If we don't answers before sprint starts we can't estimate it. If we found new issues/question during sprint we inform stakeholders and usually such story will be transferred to the next ticket.
So, my answer will be: the story don't need to be completely speced out for the sprint. But team need to know all answer to questions required for implementation as well as business decisions.
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 types changes/additions/further clarifications do you think are ok to make to a user story?
what changes/additions/further clarifications do you think are not ok to have happen to the user story?
What types changes/additions/further
clarifications do you think are ok to
make to a user story (after a sprint has started)?
Any that the Product Owner asks for and for the Scrum team still to be comfortable to maintain their commitment to completing all user stories commited to in the sprint.
what changes/additions/further
clarifications do you think are not ok
to have happen to the user story (after a sprint has started)?
Any that the Product Owner asks for and make the Scrum team not comfortable to maintain their commitment to completing all user stories commited to in the sprint.
I think this all depends on the team negotiating with the product owner. In a way, ANY changes to a user story which affect the implementation of the story are not okay.
What the team committed to was the user story as it was specified during sprint planning. Any changes introduced later were not part of the commitment, so the Product Owner (assuming that this is where the changes are coming from) should be aware that any requirement changes need to be signed off by the team.
Then again, this is a very restrictive way of handling this.
For a more real-world answer, I'd say that any changes to the user story need to be brought up to the team and negotiated. The team should be able to estimate the extra time needed to implement the changes and based on this commit to the changed user story or not. If these are little changes it's likely that you can just add the workload to the running sprint without any risks. If it's more effort, come up with a solution that doesn't put the sprint at risk and is agreed upon by the team and product owner. These could be:
Leave out another user story or reduce the scope of another user story.
Try to fit everything in but have a list of optional tasks that you can leave out if the time runs out.
Add resources to the team. Let the sprint run a few days longer.
Write a new user story for the changes and prioritise it so that it gets into the next sprint.
Drop the changed user story for this sprint, rewrite the user story and do it in the next sprint.
Even if the changed requirements pop up because the original requirements proved to be "wrong" in some way, I still think that what the team committed to is what counts. So in the case that the Product Owner decides that the user story as is has no value and needs to be changed, this is not a valid reason to bring all the changed requirements into the sprint. If the effort to apply the changes would put the rest of the sprint at the risk of failing, the better option would be to drop the changed story for this sprint and bring it up again with the changes during the next sprint planning.
The point of a user story is to define a feature that's valuable to the customer. If any aspect of that definition changes, you'd better change the story.
On the other hand, your story point estimates were based on the old story and old acceptance criteria - if changes to a user story dramatically increase the time it takes to complete it, you'll have to split the story and move part of it (or another lower-priority story) into another sprint.
It also depends how close you are to the end of the sprint - if tomorrow's the last day of the sprint, just make a new story to express the changes and add the new story to the next iteration (or the one after that, depending on its urgency).
As I recently referenced in response to another stack overflow question, I think Martin Fowler's blog post on Conversational Stories is a good one for answering questions about user stories.
Clarifications should always be welcome as part of the conversation. Changes that do not change the overall story should be permitted if the team feels it has time to complete the requested changes in the current sprint. And additions should generally be new stories unless the team feels they have the time and it would be easier for them to do it during the current sprint.
So the overall answer, is "it depends", but I think using the above guidelines will help everyone make the best decision for the team.
You can cancel a sprint. Or possibly move the troublesome items to a new sprint perhaps? Thereby reducing the length of the current sprint. But in essence I say, anything that affects the length or the output of the sprint drastically would be our decision point. Only you can really asses that I would say.
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 use Scrum. We are experiencing problems during sprints when we find the user stories are not sufficiently granular to capture the effort required to complete the sprint.
In particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons). This leads to the burndown chart looking like everything is completed on the final day of the sprint.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little and break them down into tasks, estimating the hours for each to create the burndown chart. During this day it doesn't feel like we have time to meaningfully improve the quality of the stories.
How best to break the cycle of incomplete / insufficient stories for our sprints?
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
So are you saying that:
Customers/users talk to project team
Project team writes stories and creates wireframes
Development team breaks down stories into tasks and estimates
Is there a possibility of the development team actually talking to the customers/users? User stories are sometimes seen as a way to kick off a conversation, as opposed to requirement documents/specifications.
EDIT: Some links:
A user story is to a use case as a gazelle is to a gazebo
Six Features of a Good User Story - INVEST Model
The Customer is Always Available
EDIT: Martin Fowler made a blog post yesterday on ConversationalStories that covers this far better than I did.
Are you running sprint retrospectives? At the end of the retrospective you should have high priority actionable items to improve on what happened in the previous sprint. The same things shouldnt be going wrong repeatedly.
Is your product owner accessible during a sprint? If not you may need to add extra to any estimation as the detail of a user story is incomplete.
#Pascal suggestion to dedicate 5% of your sprint to product backlog grooming is a good one. This should enable the user stories to be in a more detailed place before the start of your sprint.
We spend the Monday at the start of
each 2-week sprint going over the
stories as created by the project
team, during which time we typically
refine the stories a little and break
them down into tasks, estimating the
hours for each to create the burndown
chart. During this day it doesn't feel
like we have time to meaningfully
improve the quality of the stories.
It sounds like this is your sprint planning session, do you have control over what user stories you are commiting to complete during the sprint? How can you commit if you dont have sufficient detail?
This takes you back to having a good retrospective and solving the issues raised.
How best to break the cycle of
incomplete / insufficient stories for
our sprints?
Retrospectives, planning, backlog grooming.
Is this a failure of the project team
to nail down the stories sufficiently
at the outset, or should we (i.e. the
dev team) take some of the
responsibility?
Its the responsibility of the team as a whole. Finding blame isnt going to give value, but everyone taking responsibility will give everyone a chance of completing the project succesfully.
Maybe during those Monday morning planning sessions you can involve whoever is writing the user stories / wireframes and work together to find out what detail is missing from them, what detail would make your estimations easier and more accurate. Maybe a template of what they should include could be drawn up.
We had (and continue to in some respects) this same problem. I think this problem is a lacking of upfront analysis and a lack of devs spending enough time estimating a user story.
You might start with a story like:
As an administrative user I can create a new widget.
OK, what does that mean? After some analysis, it might mean:
As an administrative user I can create a new widget in created status with complex data validation errors.
So after that a listing of fields, how big, and what the required fields are for saving to the database. A basic UI mock up would be nice as well.
Another user story for the next sprint might be:
As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.
Then list of the complex validation rules.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little.
At the start of the sprint, the stories should be READY. If you need to refine them a bit, I think that you (the dev team, the ScrumMaster, the project team) should do that a bit ahead, during the previous sprint.
How best to break the cycle of incomplete / insufficient stories for our sprints?
You are maybe underestimating stories or they are too big and too vague. In both case, this sounds like an estimation problem and a good way to improve is to reduce the size of stories. To work on this issue, you could dedicate some time (e.g. 5% of every sprint) to Product Backlog Grooming in order to prepare the most important stories and reduce their size by putting them on diet if required before the next sprint. And this will actually make the sprint planning meeting smoother.
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
The responsibility isn't that important IMHO (except for political reasons maybe but they do not produce much value anyway), both the dev team and the project team are working together and "failing" together. What is important here is to inspect and adapt to remove the obstacle. So, it's the dev team responsibility to make this problem visible (it is an impediment). And it's the ScrumMaster responsibility to work on this impediment. The failure would be to not work on it. Backlog Grooming sessions are one way to do it. And at the end, I'm sure the project team will improve and get a better understanding of what the dev team is expecting. And you will both produce better results.
Lots of good ideas here already on the scrum aspects of your problem. Based on your comment:
particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons).
I also have a concern that you might need to work on you development process as well though. Accessing functionality from multiple locations in a UI should be a simple addition that consumes almost no time at all. If you are finding this to be a common problem then your functionality is too tightly coupled to particular UI elements. Your team might need to improve their design skills (eg: pattern usage).
This is interesting. It would appear that you are doing the sprint planning in the sprint? And that the Sprint Backlog is committed before the Sprint Planning? If so, how are the team commiting to the sprint backlog without discussing the details of the stories?
An alternative approach could be to make the Product Owner aware that certain stories cannot be added to the sprint backlog due to lack of clarity. In particular that the acceptance criteria are not fully understood. This could provoke the necessary conversation with the Product Owner. Ideally it shouldn't come to this. It should be discussed and resolved in the retrospective.