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've been using Scrum on a few projects now with varying success and I now have a query relating to documentation.
In Scrum, you obviously have the product backlog ("The application begins by bringing up the last document the user was working with.") and the sprint task backlog ("Implement forgot password screen"). However, in all the examples I have seen, these two items are fairly high level in terms of detail (being designed on fit on a post-it note).
So, where does the detail sit? Let's say the client has some very specific requirements for a stock management screen, or has a complex API that needs to be integrated with on the back end, where is this documented, how and who captures this information? Is it seperate to the backlog but populated on a just-in-time basis or some other way?
Sprint backlog
The sprint backlog is a greatly
detailed document containing
information about how the team is
going to implement the requirements
for the upcoming sprint. Tasks are
broken down into hours with no task
being more than 16 hours. If a task is
greater than 16 hours, it should be
broken down further. Tasks on the
sprint backlog are never assigned,
rather tasks are signed-up for by the
team members as they like.
Detail can sit in a wiki available to the whole team and editable by the whole team.
Not sure if this is as simple as it sounds. We've seen challenges with the detail part as well. Lets say if we're developing on a story that requires capturing simple contact information for lets say a CRM system. I now have the stories from the PO and we went through the sprint planning meeting and understood the first 5 stories that meets our velocity. However its always a struggle on capturing all the details of the conversation, for example how the screen needs to be laid out, what are the 20+ fields you need to have on the screen, can some of these fields lookup information from other tables/views etc.
Who captures those details, should it be the PO or developer and whats the best practice for storing these details. We're right now trying to use wiki's for this, however it becomes an overhead in trying to maintain the action items on who needs to update which details and by when.
My understanding is that specific requirements such as this are handled by the product owner. They will liase with the client during Sprint Planning 2 and update the tasks with specfic requirements as needed - hence why the Product Owner is a optional attendee of the Sprint Planning 2 meeting. This gives you a hybrid of Just-in-Time and Sprint Planning 2 population of the specifics. Anything that isn't satisfied by the time you come to work on the task will be an impediment and should be dealt with a the daily scrum, by the product owner.
As the development is Agile when using Scrum you shouldn't find too much of an issues getting requirements just in time.
Related
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
How can I deal with sprint backlog items that somehow becomes obsolete or unnecessary mid-sprint? Do I mark them as solved?
What about tasks that are dependent on external factors outside the control of the team?
The Scrum Guide covers this eventuality:
During the Sprint:
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
So, if you end up removing Sprint Backlog Items, your first action would be to return them to the Product Backlog. You don't mark them as "Done" because they're not, and to do so would reflect incorrectly on the Velocity.
Having removed Sprint Backlog Items, the Development Team may feel that they have capacity to bring other Product Backlog Items in to the Sprint. That's their call.
Later, perhaps during Product Backlog Refinement, you may decide that the removed Product Backlog Items are no longer useful. You could then remove them from the Product Backlog, updating any Product Roadmaps or Release Burndowns that had included those items.
I assume that by sprint backlog items, you mean what is also called tasks, or the breakdown of the product backlog items, as done by the team during the planning session. Just throw the card into the nearest recycling bin, or mark it as removed from a computerized system. You may mark them as solved if that makes sense to you (if by solved you mean no remaining work to be done).
If this happens often, then your team may wish to bring this up in a retrospective. It is an indication of the team not having a clear idea of what needs to be done - either due to insufficient planning, an impaired idea of what the product backlog item is, or possibly changing requirements. You may wish to bring it up with the PO if it is the latter.
With regard to tasks dependent on external factors - you should plan your work accordingly. Separate the high risk components from the low risk ones. have your existing (and low risk) modules interact with the high risk components through interfaces, and design the APIs to have as little of a risky surface as possible.
When building the low risk module, you should stub (mock) the high-risk modules, and you will be well served using dependency injection so that you can then easily swap the stubs for the real thing when the external factors become available. If the external modules do not fit your interface, write an adapter to transform your calls into the external module's APIs.
Even if the external factors are available before you build your software, you should consider doing the above, though developing a stub is not as crucial as it would be if it wasn't ready. Doing this will safeguard your system from future breaking changes to the external components.
Either way, your plans should account for this, and you should communicate the problem to the PO. He will not be able to release any PBI that is missing a crucial part.
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
I am a product owner and I am helping setup a themed sprint. To be clear, by themed I mean all the users stories are related or cluster around a common goal. I still have other stories that don't work well in the theme that I want to include. The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
First of all, you and your Team yourself can answer this question, because only you and your Team have the most knowledge about your situation. I know you wish there was a Scrum Manual where you could refer to some page and get the answer but you have to be factual - Scrum's simple framework never suggests that you have themed Sprints. In fact it suggests that the PO prioritize the uncommitted Backlog list of user stories based on their value and ROI, irrespective of themes, as long as the stories follow the I.N.V.E.S.T Principle, and prioritized periodically. Not that there is something wrong with theming, but if it is not working for you or your Team then you have to adapt to something new, that works for you and the Team. Here are some basic suggestions from my side:
Taking a leaf out of another members post I can say that you and your Team, need an ingredient, which is called "Courage"
The SM of the Team, along with you, needs to have the Courage to use the "Inspect and Adapt" principle to find out why fragmenting is not working for the Team.
As long as the Product Backlog is "ready" before you go into Sprint Planning, The Team needs to have Courage to trust you, the PO, in prioritizing the work for them, irrespective of their own wish or desire or way of thinking.
If fragmented Sprints is what will bring most value, then you as the PO need to have the Courage to talk openly to the Team during the Retrospective about why fragmented Sprints is the way to go, and we need to make it work until you guys find an adapted way of working in that fashion.
Lastly Everyone i.e. The Team, the SM and you need to gather the facts and notes from the above discussions, and come to a common consensus and have the courage to try it until you achieve your goals.
Keep in mind, all this needs to be done within the simple Scrum Framework rules stated in the Scrum Guide.
If you have main vision of the sprint it doesn't mean that you can't include user story which is not part of that vision. User stories are included mainly by their business priority not by their theme. So if you have user story with higher priority than your themed stories you should include it. In my opinion, themed sprints make sence only if priorities reflect splitting user stories into themes.
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 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.