For now I use 2 agile practices :
- Story mapping : to define Themes/Epics/Stories
- Stories priorisation by the ROI ( Business Value / Effort )
But, can I use both ?
For now I do the following:
1. the storry mapping, then I have my backlog and a clear view on the work.
2. Then I assign Business Values and Effort to compute the ROI (Return Of Invest) for each story.
3. Then I try to sort the stories based on ROI, that way I got what is really important first...
So, the problem is that after the last steps, the stories are mixed and I have several "long" EPICS, with several EPICS in parallel.
So, here is an example, with 3 EPICS (A, B, C), once I have ordered all the stories by ROI, you see on the bottom the "visual result" of my roadmap.
If I hide the "sotries", I lost the "Clean" vision of what will be done when, I have 3 very long bar ! So it is difficult to "understand" the planning.
How can I manage this to have a clear vision ? When I look at my "roadmap" all the EPICS are really long and so become useless. Should I split my EPICS, by putting together all the stories with the same priority ? (by example)
I have never been a fan of generating a priority order of epics as this ignores the fact that when the epics are broken down into stories the priorities are likely to change.
For example:
Epic A becomes Story X and Story Y
Epic B becomes Story J and Story K
If the priority order of the stories is X, J, Y, K then which epic is the highest priority?
My recommendation would be to only do the story mapping on stories and avoid epics or themes as much as possible.
I would attempt to do this in several phases:
First phase - first stab at the story mapping, defining themes/epics/stories.
Second phase - look at the story map and identify any epics or themes that look to be relatively high priority based on where they are in the map. Break these epics or themes down into stories.
Third phase - calculate value and effort for the stories in the story map that look to be relatively high priority.
Fourth phase - Look at the map and taking into account value and effort decide if you need to change it around so that higher priority stories get done sooner.
Repeat any of the above phases if necessary until you are happy with the prioritisation and level of detail.
One line of thinking I adopted when I first learned about epics years ago is to treat them exactly like user stories, just one level up. Hence, a user story must be complete-able within one sprint, so an epic must be sized to finish within one release period (usually three months or less). Like sprints, those periods remain the same length once chosen, for the same reasons.** It is okay to have several stories in flight in one sprint, and thus several epics in one release period. Each are rank-ordered against the others as a way of short-cutting decisions in flight. That is, if you are running out of time to complete two stories that share resources (people, testbeds, etc.), you automatically go with the higher-ranked story. Epic ranking achieves the same purpose: When prioritizing stories that use the same resources, the higher epic wins.
If you accept this premise, an answer to your question is to to "chunk" epics into single releases using the same discipline you now use to chunk stories into single sprints. I have applied this approach at several companies without issue; in fact, one program achieved 90% predictability on completing epics within a release, much higher than I expected.
**This need not block continuous delivery. It is simply a planning mechanism, intended to help customers and stakeholders know what major features are likely (though not promised) to be delivered over a period with enough time for them to plan related activities.
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 recently interviewed with a company which has started introducing Scrum for their development cycles. I asked one of the developers how their experience has been, and it sounds like they are completely divested from the planning process. He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Basically, at the start of the last Sprint (or two) he was handed a to-do list. He had to breakdown items into their respective tasks (so they could be worked on over the Sprint), but wasn't involved in any planning activities; I'm skeptical he was allowed much input into how much effort an item might take -- I suspect the architects decided this for the team.
Is this how Scrum should be handled? My current team fully participates in all planning activities, continually adding our input as to how features may be addressed and how much effort they might take. I'm a bit skeptical (and nervous) about a company which simply hands developers a to-do list without asking for their input.
Note: I understand that once a Sprint starts, the list really is a prioritized to-do list. My concern is not having input into the planning process from the start.
If those who are doing the work don't get to give input saying what amount of work can fit into a sprint and let the business decide whats most important and should be scheduled to fit. Its not going to work run away. They are using new trendy agile words but doing the same old things.
(...) He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Obviously, they're still doing command and control and micro-management (the team is not empowered and self-organizing) and they are still using push-based scheduling (they didn't enable pull-scheduling).
Scrum has other characteristics but the above points are more than enough to say that they aren't doing Scrum, regardless of how they name it, they didn't really shift from the outdated waterfall approach (they just did put some lipstick on the pig).
This is a big hint that they're still totally clueless about what Scrum is about, they didn't get it at all. And this is not going to change without some inspection and adaptation, if they even want to change. If you don't have the power to make this happen, run away.
Is this how Scrum should be handled?
No.
I worked at a place that called themselves agile. They had 6-8 month release cycles. Some things came from a backlog, but during the "Requirements Gathering" phase, basically the managers would spend a week or two meeting with various people in the company, and write up a feature list. The first day of each 4 week "iteration", the dev team would all get together and break down everything in a series of meetings. The last day of the iteration was deployment day, where there would be an intrim deployment that nobody outside of the dev team ever saw.
During the 8 month release cycle, the managers would touch base with the stakeholders maybe once or twice in the last two months of the release, at which point the only issues raised in those meetings that had a chance in hell of getting done before release were issues that were bad enough to make the whole effort useless if they were not implemented.
This is not agile, this is a variant on waterfall with a poor choice of ideas and methodologies cherry picked from other methodologies. At the end of the day, it still has all the same problems that waterfall does.
The lesson I took from my employment there is that development methodologies include things for a reason. If you are cherry picking from a methodology without fully understanding it (and by fully understanding, I mean having actually worked with it), there is a high chance that you will not use something that is actually vitally important to the whole thing. For example, in xp, kent beck advocates relying on refactoring later as a way to cut down on up front design. However, the only reason this actually works is that he also advocates TDD and pair programming. If you have a comprehensive test suite and an extra set of eyes there for the whole thing, refactoring is fairly safe. If you just cherry pick the first part and leave those two out, you are essentially cowboy coding.
I am extremely skeptical of shoppes that roll their own methodologies for this reason. There are an absolutely shocking amount of crimes being committed in the name of agile.
Is this how Scrum should be handled?
Definitely not. Scrum strives to increase transparency. By blocking developers from planning activities, they are doing the opposite of what scrum suggests.
You talked about 2 points here:
1. Sprint Planning - The Scrum Team members should be Definitely required here.
2. Backlog Grooming - May or may not be required here. You have to use your resources wisely and with common sense. One team member with strong developer background would be okay here I think.
There is one more type in Scrum:
Release Planning - Some might say developers are not needed here. But as per the Scrum Guide - "Release planning requires estimating and prioritizing the Product Backlog for the Release". Well prioritization can be done by the POs and suggested by the stake holders, but estimating would be most accurate if it is done by someone who is actually going to do the work, so it is a good idea to involve developers here. Again, resources should be used wisely. If it makes sense to not involve all developers and have people rotate turns to estimate, that is not a bad idea.
I suggest follow this structure:
Sprint Planning - part 1 : Estimation and pulling backlogs in Sprint from product backlog (PO, SM and Team are pigs here)
Sprint Planning - part 2 : Tasking, estimating task hours and breaking them down. (SM, and Team are pigs, PO is chicken here unless PO is taking tasks as well)
It is up to the team to figure out, during the sprint planning meeting, how it will turn the selected product backlog into a shippable product functionality. If they are not part of this process then they would not be able to commit.
The answer to your title question is: Developers (team) must participate in planning meetings. Planning meetings are for developers (team).
The good approach is to have two planning meetings at the beginning of each sprint: Planning meeting 1 and Planning meeting 2. In Planning meeting 1 Product owner gives prioritized (and size estimated - size estimation is not done on planning meeting) product backlog to the team and team starts to discuss most prioritized user stories. For each disucssed user story team should be able to collect:
Detailed requirements (for example which fields the input form has to have ...)
Constraints (for example how fast the functionality has to be)
Acceptance tests (verification of results)
UI sketches (for example how should UI flow looks like)
Acceptance criteria (validation from end user - acceptance criteria doesn't have to be real test. It can be something related to "easy to use" etc.)
There should be time boundary for Planning meeting 1. Number of user stories you were able to discuss can correspond to number of user stories you will be able to complete in upcoming sprint. At the end of Planning meeting 1 team must make commitment - say how many of discussed user stories will be done in upcomming sprint. Sprint planning meeting 2 is only for team because team further discusses user stories and breaks them into tasks.
Generally, of course they should. Obviously, it's never realistically possible to the degree that developers would like. However, if sprints are usually "Hair On Fire" type affairs, where the developers get no serious input at all... then at the very LEAST there should be regularly-scheduled "entropy reduction" sprints, where all tasks are selected exclusively by the developers for the purpose of cleaning crap up.
At least some developers need to be there so work can be properly estimated and pipelined.
But not all developers need to be there. All can be there is it makes more sense.
On the other hand, developers need to understand that the business priorities are the priorities, no matter what they think should come next. Everyone has to work together ot make it work.
I'm not so much worried about my input, but about my insight. I recently was involved in a project where I had no knowledge of the project before the plans were handed to me supposedly complete. The nightmare started when I discovered that the process was not completely thought out and the data definitions were not complete. I wound up having to go through the whole process again to get the answers that I required.
The Team can be involved in the planning process without a formal process or meeting. The planning process is really very fluid. At the start, the goal should be to get to starting sprints ASAP. Spending too much time in planning before the first sprint feels very waterfall and is a waste of everyone's time. I, as a team member would feel relieved to not be a part of that, except for the fact that it indicates a dysfunctional nature to the organization. The Team should always be free to voice ideas on an ongoing basis (since that's when the real planning happens). But, 2 things you mentioned concern me most.
First, the Team should be the only ones to determine how many backlog items they can do this sprint. They certainly would be involved in estimating the effort. That's a big problem.
Second, the Team does not sound like they have access to the product owner (maybe there ins't even one here). Even if the team has not been involved in the "planning" thus far, surely if I were talking to the product owner in the planning meeting, or had access to them at other times, I would voice suggestions over time.
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 in the process of developing an new product and implementing Agile, specifically Scrum. Our first sprint was planned conservatively, but we are going to miss our target by quite a bit. The main cause being interuptions and new clients throwing in last minute requirements that we had stop and react to.
To be able to help identify our weaknesses and also so I can get some fodder together for a retrospective of our first sprint, I am interested in hearing about companies developer head count versus user head count. Is your ratio/mix a successful one? Only for internal development, not software houses or tech companies. Any opinions on the subject are also welcomed, I think it could open an interesting discussion.
The main limiting factor is always budget, so there is no need to include that in any opinions.
Don't be too upset with failing your first sprint. It is rare to do anything 100% the first time. Most first sprints reveal problems that have to be fixed - just as it was in your case.
Your problem has nothing to do with the users / developers ratio. Your problem is properly insulating your sprints and making sure the basic Scrum deal (no scope changes mid-sprint, all scope changes between sprints) is adhered to. Things to do:
Make sure everyone understands Sprint Backlog can't be changed between Sprint Planning and Sprint Review. If anyone tries to force this play by the book: do abnormal termination, throw away all the work work, plan a new sprint and make all of the fuss about it. The reason Scrum calls for this is to make the cost of interruptions and scope changes highly, painfully visible.
Shorten your sprints. Two week sprints worked very well for us because it was pretty easy to explain to any manager type that he can wait 2-3 weeks for his feature. Our PO got pretty good at this eventually.
If for any reason you have short fixes / features that can't wait two weeks institute a "firefighter" - devote one developer per sprint to handling such issues, don't plan any regular work for him. To avoid burnout make it a rotating function - someone is the firefighter each sprint. Hey, you could even buy them a firefighter hat. :)
We did 1 & 2 after our first sprint (way back in 2007) blew just like yours. It helped a lot, so we didn't have to do 3. I advised 3 to a team that had such need and it worked pretty well.
If you allow new requirements during a sprint for this sprint, you're not doing scrum.
The only thing I would allow, are critical bugs in producitve software. These have to be fixed. Here one would allocate one or two devs per sprint who are responsible for bugfixing, if the need arises.
Too many users is not (should not be) a problem. The developer to user ratio depends on the type of the product and the industry/domain, not on the methodology. Small shrinkwrap products (developed by a minimal team, or even a single person) can have millions of users (e.g. Total Commander), while huge internal enterprise products developed by a team of hundreds can have half a dozen users.
The problem is rather that apparently your users are not familiar with Scrum, and you are not using a single product backlog (or haven't taught your users about it).
You should have a single product owner, who decides about what gets into the next sprint, at the start of the sprint. Last minute change requests are (ideally) not allowed - they can only get into the next sprint. It is the product owner's responsibility to communicate with the users, collect and evaluate feature ideas/requests, prioritize them, and OTOH communicate these towards the dev team. In other words, users should never ask features directly from individual developers; they should turn to the product owner instead.
The essence of scrum sprints is that you can't interrupt them with last minute requirements.
Regarding the ratio you are talking about, it depends greatly on what your product is, in which industry you are, and lot of things like that. So to make this value useful, you will have to experiment a bit.
But your developers should rely on your product owner, and not your user base (regardless its size).
Sprint is safe zone. At the beginning of the sprint team discusses product backlog items with product owner and selects subset of these items to be done in upcomming sprint. Team commits to these items. It is team responsibility to deliver commited items so no one can introduce new items during the sprint except the team (this usually happens when items are developed faster than was expected).
Each SCRUM project has to have one Product owner (if there is more than one, there has to be hiearchy) which is responsible for product backlog. If the product owner demands new items during sprint the only way to do it is to cancel current sprint and start the new one.
Possibly a more meaningful ratio would be developers : features/projects. If a manager commits all available resources to a sprint, then there is a higher probability that you'll need to interrupt at least one of them for a critical support issue (for instance); it's a slippery slope to things like "well, you're ahead of schedule, so can you slip this extra functionality in", at which point you've broken one of the core principles behind SCRUM.
I get the feeling you're about to start a campaign for more headcount in your department, to relieve pressures on the current team; perhaps a better long term approach would be to manage expectations of your customers (be they internal or external), so that your existing headcount remains flexible to jump in and handle interruptions; at the same time they can manage expectations that additional requirements get deferred to a later sprint.
developer head count versus user head count
I'll probably get downvoted for that but I think it is largely irrelevant.
There are fantastic products built by a couple of guys serving millions of users.
Just as there are projects developed by a huge strike force which never crossed the threshold of mediocrity.
User head count / dev head count is not a relevant metric.
You can have a single user that generates huge amounts of change versus hundreds that don't generate any (of very little) change.
What is relevant is the amount of change being requested and how it is managed and tracked.
If you can show how much the requirements have changed while still implementing and designing for other requirements you will have your fodder.
One of the biggest mis-conceptions about any Agile methodology is that you can make it up as you go along.
And although this generally true, the key thing is project management and communication.
Like a lot of things in life you can do anything, but there is a consequence. If I buy a Ferrari can I afford to eat?
If I ask for an extra bit of functionality how much is that going to affect the project.
So during planning
MoSCoW (Must, Should, Could or Wont) requirements
Estimate how long it will take
You cannot fill a Sprint / Timebox with Musts or Shoulds
During the sprint / timebox
Monitor the time it takes against Estimates
Re-plan
When an interruption occurs. Log it and feed this into the Time Taken requirement. Next set of estimates include and interruption factor. Estimation within Agile is an Artform!
When changes are asked for
Estimate how long it will take, compare with original estimate
Inform the Business User of the effect
Prioritise within the MoSCoW
Communication is important. If you want me to add that button there, I will not be able to print the invoice.
Because of MoSCoW it maybe that in sprint 4 the item which is a Wont might make it's way up to a Should or a Must.
Also treat Agile as a toolkit you do not need to prescribe to SCRUM or any other methodology pick the important bits which work for the culture you are in.
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 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've been learning Scrum and trying a tool called Acunote for use with it. My question is about two fields I have there, for each task. They're "estimate" and "remaining". What unit should I use for those? Do I use Story Points? What about the remaining? For example I have a task that will take 10 units, let's say. I fill the remaining at the end of day with how many "units" I believe it will take me to complete?
Thanks!
I have a few suggestions for you:
If you are new to scrum; use a whiteboard and don't get bogged down in a particular tool's semantics; it will hamper your learning and adoption.
Break your stories small enough so that you don't have to create and estimate Tasks.
Don't do anything with hours, it is a waste of time to estimate at that level.
Burn down story points.
It is all too easy and common for teams to "think" they are on track because Tasks are being completed and burned down. Then they get to the end of the sprint and find that 5 stories are all 90% done and nothing is completed. If you burn down stories you are actually tracking deliverable business value and not just an arbitrary amount of developer-junk.
As always, my first advice would be to not use a tool when adopting/learning Scrum (I start to be tired to repeat the same thing over and over :). Instead, start with the simplest thing that could possibly work (a spreadsheet for the Product Backlog, a white-board and post-it notes for the Sprint Backlog). The rationale behind this is that you want to learn and master Scrum, not a tool. So don't let a tool tell you how to do Scrum and drive the process.
Then, regarding the question, there are 2 schools of thought: 1. what Scrum says in theory, 2. what some people do in practice.
In theory, Scrum has two levels of estimation: one for work (Tasks) to be completed within the current Sprint and one for more distant Product Backlog Items (PBIs). At the Product Backlog level, items (the "what" is being built) should be estimated in Story/T-Shirt/Unit-less points which have a low degree of precision. This approach avoids "analysis paralysis" pitfalls and accurately reflects the general uncertainty surrounding the work in question. At the Sprint Backlog level, items are beaked down into tasks (the "how" a PBI will be achieved) that are estimated in hours. A separate estimation scheme is appropriate because Tasks describe granular work (usually on the order of a few hours, never more than 16h). In fact, Scrum recommends using "ideal engineering hours" for Task-level estimates.
In practice, some people don't estimate in hours because burning down hours doesn't show "real" progress, which isn't false, and they prefer to burn down Story Points (which really means an item is done or not, it's more binary).
While I understand the "spirit" of the later approach, I don't apply it and stick with the theory. Actually, for the reasons previously mentioned, estimating in hours does make sense to me and I actually find that it gives better "control" of the Scrum empirical process during a Sprint (at the end of each day, you should update the estimated remaining work regardless of the actual time spent and this is easier with hours).
Moreover, I don't like the drawback of having only small stories (which can be seen as waste too) but like when a team identifies clearly what has to be done within a Sprint (this is good for transparency and helps the Product Owner to understand the real amount of work too, especially "quality oriented" tasks).
Finally, I think that you can avoid the pitfalls mentioned by DancesWithBamboo with hours too. Just stay vigilant and:
Always focus on the most important PBIs (and related tasks) first.
Pay a special attention to non-finished tasks, they should keep moving on the white board (if you are using columns to represent steps like for example "todo", "in progress", "to be verified", "done"); a non moving task is a smell.
Don't start a new item before the previous is done.
So, in my opinion, it is possible to use hours and to avoid the "nothing done" at the end of the Sprint syndrome. Just use your brain (Scrum and/or any tool won't replace it, luckily for us).
Having that said, and if you don't throw your tool away, the questions to answer are: what do you want to show on the burndown (points or hours depending on if you breakdown the work into tasks or not, I gave you my point of view) and what field does Acunote use to draw the burndown (i.e. where should I update the estimation of the remaining work). If you choose points and don't use tasks, it wouldn't make sense to update remaining work unless it's totally done IMO (a PBI is done, or not).
IMHO you shouldn't use remaining for the SCRUM points, because the points should be really subjective and you probably can't say how far you have gone.
I would recommend that you break the task into smaller ones (these ones would be the steps you need to implement the features) and then estimate them into hours. This way you can easily track the progress of the feature
Use hours for both the initial estimate and the remaining time. Tasks are usually estimated in hours.
You can use Scrum point - or any other unit - to estimate the backlog items.
I would not bother with remaining. A story or a task is boolean (either done or not done).
In our team we started to accept only tasks that are expected to have less than a day. That way no team member should be working on the same task on two consecutive daily scrums. The third day for sure rings alarm bells!
Also breaking up in task is easy and fast, because it doesn't take much estimating. Is it less than a day: OK, otherwise break it down.
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
Having used "days" as the unit for estimation of tasks in Scrum I find it hard to change to using Story Points. I believe story points should be used as they are more comparable to each other - being less dependent on the qualifications of whoever addresses the task etc. However, it isn't easy to make a team start using Story Points when they're used to estimating in days.
So, how to make a team change to Story Points? What should motivate the team members to do so, and how should we apply the switch?
When I switched to points, I decided to it only if I could meet the two following points; 1) find and argument that justify the switch and that will convince the team 2) Find an easy method to use it.
Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.
Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.
Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value
If you want to change to using story points instead of duration, you just got to start estimating in story points. (I'm assuming here you have the authority to make that decision for your team.)
Pick a scale, could be small, medium, large could be fibonacci sequence, could be 1 to 5, whatever pick one and use it for several sprints this will give you your velocity. If you start changing the scale from one to the other then velocity between scales is not going to be comparable (ie dont do it). These estimates should involve all your Scrum team.
Having said that you still need an idea of how much this is going to cost you. There arent many accountants who will accept the answer "I'll tell you how much this is going to cost in 6 months". So you still need to estimate the project in duration as well, this will give you the cost. This estimate is probably going to be done by a senior person on the team
Then every month your velocity will tell you and the accountants how accurate that first cost estimate was and you can adapt accordingly.
Start by making one day equal one point (or some strict ratio). It is a good way to get started. After a couple of sprints you can start encouraging them to use more relative points (ie. how big is this compared to that thing).
The problem is that story points define effort.
Days are duration.
The two have an almost random relationship. duration = f ( effort ). That function is based on the skill of the person actually doing the work.
A person knows how long they will take to do the work. That's duration. In days.
They don't know this abstract 'effort' thing. They don't know how long a hypothetical person of average skills will require to do it.
The best you can do is both -- story points (effort) and days (duration).
You can't replace one with the other. If you try to use only effort, then you'll eventually need to get to days for planning purposes. You'll have to apply a person to the story points and compute a duration from the effort.