Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are just beginning to move from Waterfall to Agile. One of the few complaints about our new process is that our iteration planning meetings are taking too long, mostly because we are writing our story cards in the meeting itself, which was how the process was described to me.
One suggestion was that we write the story cards ahead of the meeting and ask everyone to review them before they come to the meeting as a potential time saver.
Is there an advantage to doing the stories during the meeting, vs. writing the story cards ahead of time and asking people to review them ahead of time, potentially saving everyone some time?
This is probably not an ideal question to ask as there's no real definitive answer. Responses are likely to be subjective.
Relating to my own experience, our team tends to get Stakeholders and Product Owners to add User stories in an adhoc fashion during our sprints to a projects product backlog (we work on a web application and are user driven in terms of functionality - we do have a roadmap, but we also adapt to feedback etc).
That way, when it comes time to do iteration planning we have a brief Product planning meeting with Stakeholders, Product Owner and project leads to discuss priority and adjust User Stories on our product backlog.
Once that's done, there's a subsequent Sprint Planning session with project teams that pluck off User Stories to work on in the sprint (picking off enough User Stories that we feel can be realistically achieved when gauged against our established velocity).
I'm sure other people do it differently, the key thing is to find something that works for you and your team.
which was how the process was described to me
You identified a problem in your process (too long planning meeting) and found out the root cause for it (writing story cards). The most sensible and agile thing to do is probably not to stick to "how the process was described" but to adapt accordingly, which means creating the cards in advance.
That said, from my personal experience, the sooner user stories are presented by the Product Owner to the team the better. Sprint Planning will probably be when story estimates are refined and little details are tackled, but it's generally better if the team did at least some exploration and estimation ahead and don't arrive at the meeting completely ignorant.
One of the most important purposes of User Stories is to serve as a conversation starter among developers and stakeholders. Based on my experience, it can save a lot of time to have one or two people review all of the existing requirements or requests and translate them into user stories.
But it is vital that the story cards get discussed, and that should take considerable time. Even though it seems like a lot of time that could be better spent on development, the reality is that, without discussion, development can easily go in the wrong direction. Asking people to review the cards ahead of the meeting often does not work - if they don't want to take time to discuss the cards during the meeting, they probably won't review the cards on their own time.
My advice: ask two people to work together on writing the user stories ahead of the meeting, but use the meeting to review and discuss each card.
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
I'm starting with Scrum. I have read about it but as a newbie I feel uncomfortable about a lot of things.
These days my team is starting the creation of a new game. We know the key elements of the game but we don't really know how they will really work. I would like the team to spend 1 or 2 weeks brainstorming and defining how the elements work. As an example one of the elements could be a grid of pieces where user clicks the pieces to destroy them.
Can this be converted into a user story or this is not the kind of thing that is converted into a user story? I was thinking about writing the user story this way: "As a player I would like to know what am I able to do when I interact with the grid of pieces". With this requirement I could justify the time spent in the design stage of this element.
I know a user story is something that the product owner adds to the backlog to provide some value to the project. For me in the design stage this would provide value because stake holders would know exactly how things work before starting real development.
Thanks in advance.
A user story should represent value to an actual user, not just a part of the development process. Start with a story like "Player plays the game for a few turns" or just "Player moves a piece on the board" or whatever you think will fit in to one sprint. Include in your estimation the time needed for all team members, designers and developers, to contribute. When you've implemented that story you'll have something a real end user will care about. It will be terrible, since you're just getting started, but you can write more stories to address that in later sprints.
It's important to keep in mind that stories are "a reminder for a conversation" and that the product backlog is not static, but evolving over time.
Let's say you start with something relatively imprecise as "player can destroy pieces placed on a grid." No details as to what that means yet.
When you arrive at the Sprint Planning meeting, the Product Owner indicates that this is the highest priority item, and everyone agrees that the Sprint Goal will be to figure out different ways to destroy pieces. You could proceed two ways here, depending on how much you know about destroying pieces.
If you have some ideas on how that could be accomplished, you could have a quick brainstorming session during the meeting. Let's say that, as a result, you identify 3 different ways in which that could be done. The original story is then split in 3 pieces, and then the team needs to decide how many of those they could implement during the sprint. Something important to realize here is that you can consider this early implementation as an experiment that will provide you later with more information to further refine the ideas.
If you have no clue about how this could be done, you could add a "spike" to the sprint. A spike is a time-boxed experiment designed to gather information to implement another story. So in essence, you're scheduling research time and deferring implementation for later, but the research is time-boxed and expected to provide implementation options.
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 8 years ago.
Improve this question
I'm starting to add first user stories to my game backlog. My team has a rough idea of the game we want to create and we are ready to gather top level requirements. How do you do this? I mean, for example you can start with a mega epic (top level) that reads "As a publisher I want to create a game where player must feed a monster so that they spent a really fun time". Is this a correct starting point? Should we now split this epic into smaller user stories and split this user stories in smaller ones and finally in tasks? Is this "tree like" way of gathering requirements good or you usually use a "flatter" way?
Thanks in advance.
That is what we do. Start with epics that are fairly high level and the decompose them into more technical user stories. Generally we stop at one level, but sometimes a user story is just too big and it does need to be split into smaller chunks.
At the top level are epics, and right below are user stories, and that is it. It may help you to break down further as an exercise in decomposition - but building a massive tree of dependent stories might be a lot to track. We try and capture stakeholder needs AS epics (and yes, there can be some overlap, but that's ok.) We tend to want our user stories to be "lightweight requirements". The developer is free to create as many tasks as necessary to accomplish the story. And if the dev finds that there are just too many tasks, we go back and see if we can break the story up.
Our Product Owner manages a "feature backlog" which is just the fancy way of saying "epics". We link the feature stories to our team stories. There is not ONE top level epic, there are MANY top level epics representing feature needs. This way we can group features logically together for the sake of "releases".
You might want to take a look at a technique called "User Story Mapping", by Jeff Patton.
"As a publisher I want to create a game where player must feed a monster so that they spent a really fun time"
Something to keep in mind is that stories are written from the perspective of the users of the system. In the example you mention, it occurs to me that the Publisher is definitely a stakeholder for the project, but not a user (unless you're creating an app to generate games on the fly.)
Start by doing an analysis of users of your game. Probably "Player" will be the main role, but you can think of different kinds of players: advanced players vs. newbies, PC players vs game console players, players who want to explore vs just get through the game fast, etc. That will suggest you different features the game needs to support.
A good starting-point for writing good user stories is the book by Mike Cohn. There are also plenty of useful resources online how to write good user stories and how to work with the backlog as a Product Owner and how to involve the team to continuously keep the backlog in good shape so you can have effective sprint planning sessions, do reasonable forecasting of dates when features will be available etc.
It's always important to stay practical and experiment. Start with something and then inspect&adapt that so that you improve. This is the essence of any agile tool/framework.
If you want, start with the big epic and see how that goes.
Probably it's not worth having that epic, but rather discuss various things the player of he game can do that are more specific. These things are user stories, i.e. things that add user value throughout a whole product. A vertical slice of the system.
Some made-up examples to illustrate ideas around stories in a game setting:
Player that gets 100k points will get rewarded with a golden medallion.
Player must complete X and Y in order to open up the secret passage in Z.
Player can use portal to teleport to any level he chooses.
Yes you can see it as a tree or more and more specific stories that are children of other stories or epics. Practically, you only care about the leaves as that is the product of working together as the team and PO to work on backlog items during sprint planning or other sessions.
Experiment and start with something and improve from there.
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 8 years ago.
Improve this question
During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.
Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.
We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.
We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?
Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.
Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.
We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.
I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.
It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:
Your velocity is unfortunately 0 because no stories are Done. I would encourage the team to consider:
What went wrong with the unfinished stories? What stopped them getting to Done?
Were the stories too large or complex? If so, how could they have been broken down? Beware splitting the stories into "layers" - stories should be split into vertical slices so each story still delivers an increment of user value.
Did the team start too much and not focus on finishing what had already been started (too much work in progress)?
You might need to remind them that the team as a whole succeeds or fails - if one part of the team struggled it was up to the rest of the team to support them and come up with a solution.
As discussed above, stories should be vertical slices of functionality, not horizontal ones. This is tricky because software engineers often think in "layers". How can you overcome this with the "tiered" team? In particular, how can you avoid hand-offs between the three groups (hand-offs are expensive and cause delays). Some thoughts:
Could the Data team have provided a stub (e.g. an interface that returns hard-coded dummy data) to allow the UI and Services teams to proceed while the data layer is being completed?
Could a cross-functional group have swarmed on each story (so all three "tiers" are forced to work together on completion of a story)?
How can the tiers cross-train so they can take on work outside their specialist areas (this is the concept of "generalising specialists" or "specialising generalists"). This will allow them to support each other when the going gets sticky.
Is the scrum team too large (probably)?
A "two pizza" team of 5-9 members is ideal
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
Each scrum can work independently on an epic
Outside the retrospective, the scrum master and product owner might want to think about a couple of things:
Backlog management is really important (and really hard to get right) - it sounds like you have done lots of work on this, but it is vital to keep it up. A poorly groomed backlog will stall the team.
If you have silos (e.g. between the "tiers"), you need to work to break them down. Silos reduce the team's flexibility and create hand-offs which are expensive.
Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.
Bids has given good advice and what I consider the answer to the headline question but it is buried in there. I wanted to explicitly call it out:
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
In Scrum stories are intended to be vertical slices through the system. You should restructure your teams so that they have the expertise to develop the end-to-end features. This will make a huge difference and I would try this before doing any other tweaks.
Not finishing any stories is pretty bad. You should limit the amount of work in progress.
I would recommend that you give the team only one story and make them work together on it. They're obviously a brand new team, that need to learn to walk before they run.
Would this be wasteful by not fully utilizing team members? Maybe, but the team haven't proven they can actually deliver anything. At least delivering one thing would prove a certain level of productivity and it would force them to actually work as a 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
Scrum and agile says that items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
Practically, that never seems to work for our team. Either the item is too small for all team members to be productive (including taking pairing into account). So we end up perhaps doing two or three items across the team at any one time.
I'd be interested to hear how other teams do it, and also how many items they usually commit to in a given sprint.
items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
I don't know who says this, I at least don't remember having heard or read anything like the emphasized text so far. Of course, it depends also on whether an item for you is a story or a single task.
If it's a story (usually consisting of several tasks), there might be a chance of achieving this. However, as you say, sometimes the story just doesn't include enough tasks to keep everyone busy. Also often the tasks related to a story strongly depend on each other, e.g. there might be a design session (involving part or whole of team), then one or more coding tasks, then code review, functional testing, documentation etc. Obviously one can't do functional testing before the coding, and so on.
Since everyone has to do something, there will be at least as many tasks open at any given time as there are team members (or pairs). Taking into account that sometimes tasks are on hold for various reasons (inter-task dependencies, information needed from external parties etc.), usually even more.
In one Scrum project with a team of 4 developers, we had a very similar situation. We did strive to take stories in priority order as much as possible, and usually we had multiple stories and several tasks open at any time. In the beginning we often had problems with several half-finished stories at the end of the sprint. So we realized it is important to keep the number of open tasks / stories to a minimum, i.e. always attempt to finish open tasks /stories first before starting a new one. But practically, that minimum was never meant to be 1.
As for the number of stories per sprint, we just put in as many as we could comfortably fit in based on our (story, then task level) estimations. That was of course greatly influenced by our velocity, which in the beginning was estimated too high. After a couple of months we chipped it down to 60%, and that value seemed to work for us.
The advice to approach each item by the whole team is there to avoid creating mini-waterfalls within sprints, where items are passed from one specialized group to another. That leads to stuff like testers having nothing to do in first days of the sprint, then working overtime for the last couple of days when coders fiddle their thumbs. Teams should approach the problem as a whole with everyone chipping in, even outside of their respective "specialization". Yes, coders can test, testers can code and both can design architectures etc. - and in the process learn something new (amazing). That is not to say everyone should be very good at everything - it is just to say attitude like "I don't test, I'm a coder" or "I won't write this script, I'm a tester" should have no place in a Scrum team.
It is also advised to tackle items one by one inside of sprint to make sure something is actually delivered at the end. Limiting work in progress (WIP) prevents situation, where everyone did some tasks on each item, but no item has been completed by sprint's end.
However, this shouldn't be viewed as advice, not a very strict rule. For example when you have two small stories and a team of 10 it probably doesn't make sense to have all of the team swarm on just one story.
Bottom line is: no one should tell the team how to divide work among themselves, but delivering what they committed to at Sprint Planning should be expected.
I think it depends on the makeup of your team. If you have a team where anyone can take on any given task within a user story, then this works well. If you do not, then there will likely be idle time for some individuals.
The point in working the user stories based on priority is simple... you get the highest priority user story completed first. This adds the most value from the perspective of the customer who actually set the priority.
As for how many user stories to commit to during a sprint, that depends on a few factors:
Team Availability, Team Velocity, and Sprint Duration. So, I'm not sure how much value you will get out of knowing how many stories other people tackle during a sprint.
Noel, is your team trained to work in a Scrum team ? I mean did you send them to Scrum Course prior beginning the project ?
I've seen so many team failing with Scrum just because they misunderstood what was written in a book on a blog.
Also having an experienced Scrum Practitioner or Scrum Coach will help you a lot.
To answer your question specifically, check this nice free ebook that is different than others:
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.
EDIT: Additional Information:
We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.
EDIT: More insight/confusion perhaps:
I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.
Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.
If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.
Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.
Take an interation to rework or bug squash. That should give the BAs sometime to get ahead of the curve.
If, however, the problem is that the BAs need to see the previous requirements in the "wild" before making more requirements you have much bigger issues. :)
At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.
Update to respond to the questioneers Update
It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"
Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.
I take it that there is no sprint planning sessions from what you say.
Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:
Apart from having short sprints that is.
Well, a couple of things might help
- In the SCRUM process, there is the concept of Product Owner wchich is a Pig Role, this represents the customer. So you can invite the PLM or the client's main contact to your SCRUM's meeting. This will give your customer's some buy-in into your process and will get them to work "with" you on your goals
- Weekly builds to the client might help. So, the basic idea of the weekly drops is to show the customer "progress". So if for a few weeks there is no progress, this should raise the question "why?" and then you should be able to explain that it is for the lack of requirements finalization.
Hope this helps
the "user story" is a placeholder for a future conversation, so get in front of the customer and ask them; if that's the BA's job, light a fire ;-)
Your user stories are incomplete. 'Customize X screen' is a task, it doesn't describe any requirements or completion criteria. The user story should be something like 'Allow Nancy to see the related purchase orders for an item in inventory'. Then break that down into tasks during your sprint that you can work on.
Once the BAs have developed a workable user story then add it to your product backlog, prioritize it, and plan your sprints for the top backlog items. The BAs should be developing user stories and adding to your backlog independent of your sprints, and thus not blocking you. During a sprint the tasks are completed and the user story does not change. After releasing the customer provides feedback which goes into the product backlog as more user stories.
I see a few ways to handle this:
Option 1, Under SCRUM, you should have a Product Owner who is managing your product backlog, which is supposed to contain requests for features of the software. If the feature consists of something vague like 'Customize screen X' and you decide to add that to your sprint, then the sprint tasks should be concrete, decomposed tasks, and I would say one of those tasks has to be 'Define requirements for screen X'.
During the daily SCRUM, when you're asking your three questions of each team member, the developer who has that screen mod task will say "I'm blocked waiting for requirements from the BA.", and your scrum master does what they can to get that moving along.
option 2, in my opinion, is that items do not go into your product backlog until they're defined well enough to do at least some productive work on. We all know requirements change, but the point is that you're supposed to have enough to start with.
Easy.
Allow yourself to think outside of Scrum's strict rules, and get back to your lean roots:
http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/
http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Trust me, once you get that flow going, you'll never look back.
As it is said above, usually at the beginning of each sprint you should prioritize the existing backlog and pick some stories for the current sprint. If there is not enough user stories for the developers, you should shift developers to another project and let the product owner some time to create a decent (=large enough to feed some team) backlog for the project.