Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm starting a new interesting project and, with my team, we are looking for a way to define the our checklist in order to have clear ideas (as much as possible) on what we have to do in order to release a feature starting from a user story.
I've found many interesting resources:
Scrum Checklist
ALL ABOUT AGILE
...and something else
So, my proposal is to start a discussion with someone that is experienced in that question.
Hope someone help me!
There are various things to consider when choosing to develop a project using Agile methodology.
Roles:
Product Owner:
Defines features of the product
Decide on release date and content
Prioritizes and adjusts features every sprint
Scrum Master (typically a developer):
Manages the project
Ensures team is fully functional
Enables close cooperation across all roles and functions
Shields team from external interferences
Ideal Scrum team size ~7 people.
Stages:
1) Create a product backlog (list of user stories):
Using a list of requirements given by the client, create a list of user stories.
2) Conduct a planning poker session:
Only developers are involved in this session, clients may watch but cannot interact.
The purpose of planning poker is to assign a "Story point" value to easy of the user stories.
A story point value is the estimated "effort" of developing a story.
Set up a series of poker cards that range from 0 to 100, the series of cards I am familiar with are 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 100.
Each developer is given a series of poker cards. A user story is read aloud to the group and each person will have a few seconds to pick a story point value. Values picked are shown at the same time. If a consesus has been reached, move onto the next story. If not, there should be a quick discussion on why you picked your value, and another round of planning poker begins.
If a poker value selected is greater than 20, you should consider breaking the user story down into small stories.
3) Sprint planning:
Sprint Backlog is created
Team selects items from product backlog which they can commit to completing
Tasks are identified and each is estimated
4) Sprint:
Ideal duration = 2-4 weeks
Daily scrum meeting:
Ideally early in the day. Stand-up, quick meeting. Managed by Scrum Master. 3 questions are asked each meeting; What did you do yesterday? What are you going to do today? Is there anything in your way?
Design, development and testing done throughout sprint.
5) Sprint review:
Scrum team present what they accomplished during the sprint (demo new features)
Attendees - Scrum Team, Product owner, stackholders
What went well, problems, how problems were resolved
Demonstrate what user stories are "done done"
Receive feedback from Product Owner
6) Sprint Retrospective:
Occurs after Sprint Review and planning for next sprint
Look at what is and isn't working
Inspect how the Sprint went
Create plan for making improvements on how the scrum team operates
Develop better processes/practices
7) Repeat Stage 3
Plan next sprint using same processes as before.
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
We have a team of about four developers working in Scrum with two week sprints. We use YouTrack and when performing time estimation in Sprint Planning, we hit the two weeks of work quickly.
The issue is, for example, developer John will pick the first item on the backlog and say it'll take about 1 day. Developer Brian will take the next item and say it'll be about 1 day. Of course, that's actually only one day's work if each developer works on each piece, but YouTrack will sum it as 2 days.
When the whole team doesn't have to work on the same item at once, how do we appropriately estimate time? Are we breaking Scrum rules somewhere?
If we're doing it right, and we have to just go over two weeks, how do we be sure we're not giving ourselves too much work?
It should NOT be only Complexity but include Complexity, Effort, Risk and a gentle touch of common sense.
I think you are estimating in the wrong way to begin with, which has nothing to do with Scrum, Kanban or XP. You are estimating in a per person basis which should be actually done on per Story basis. Think about the feature as a whole and then estimate the story and not individual member's effort towards it.
Estimating by man days/hours have always been criticised as it doesn't involves the skill set measurement. Say, one feature with complexity 5 can be done in 1 day by a senior engineer but it will take 2 days for a new joiner or less experienced member. Hence, you can't take only complexity into account to measure the story sizes and sprint commitments.
Many people estimate Stories using complexity only and then sub-tasks according to hours, that has drawbacks as well due to duplication of effort in the actual estimation. Above all, always keep in mind that an Estimate will always be an estimate and Planning poker can only help you find it but it is not the ultimate estimation technique.
Adding my five cents here, complexity of the backlog items is not judged by individual team members.
First of all, a backlog item most likely involves more than a single team member and could be broken down to smaller tasks like 'implement UI', 'run tests' or 'change the database schema'. So there will be both John, Brian and maybe also Mary (a testing engineer) involved. And thus you'll need to estimate 'Complexity, Effort, Risk and a gentle touch of common sense' for the whole team, not just for John or Brian.
Also John, being a senior guy, might say it is of complexity 2, while Brian (a junior) could say it is 5 and Mary will notice a lot of regression because of the database schema change and give it 8. In the end in Scrum it comes to the whole team's commitment for the sprint. So you, as a Scrum Master, will need to facilitate John, Brian and Mary to come to an agreement and here's where tools like planning poker come to the stage.
As far as I know and understand, you don't estimate effort in Scrum. You estimate complexity of user stories in relation to each other and the contained functionality.
Following this, you estimate story points, not man days. The burndown chart shows your team's progress. Over time you get quite an accurate team velocity which basically tells you how many story points your team gets done with per sprint.
Use this team velocity as a basis to decide whether to commit to another user story for any given sprint, or if it will probably be too much.
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 was going through the definition of Velocity of a project. As per my understanding its the number of story points acheived vs planned in an iteraction.
I am not clear on what is a story point?
Story Point is an "arbitrary" unit of work assigned to a particular task or story.
It can be the number of man-hours the team (or the team leader) estimated the task/story would take, but it could be just any other unit of work/time.
The specific unit used for a Story Point is somewhat arbitrary in a sense that it doesn't even need to translate into a precise amount of man hours (or of work days or what not). The only requirement is that the Story Points reflect the estimated amount of a work each task or story will require in a consistent fashion.
If the story point are assigned in such a consistent fashion, story points become a useful metric for measuring progress on the overall project. Also, if the amount of work programmers can perform during a given span of time (say during a 2 weeks "sprint") is expressed in story points, it is possible to plan the list of stories that can be delivered during the sprint (if all goes well ;-) )
A story point is something used by the scrum to estimate work effort on a story. It's an arbitrary measure such as person-hours, or a simple {easy-peasy, one-for-the-graduate, medium, guru, crikey-thats-a-toughie, near-impossibility} ({1, 3, 9, 27, 81} sort of thing) selection.
Hence a fairly simple story (hello, world) might be one story point, while a more complex one (a Facebook clone) would be many more.
Really good teams will maintain a history of stories and their points (both estimated and actual).
That way, you can just go find an earlier story similar to the one you're estimating and use its actual point count (found once the story had finished) as a baseline for the current story.
See this entry in the Agile FAQ for more detail, or the top page for lots of other goodies.
It is the complexity of story that is used to measure the team velocity. Normally, it is not precised hours the story will need because you can't know specially when you are a new agile team. But with time you will be able to more precisely assign a number to story because you learn with time.
Since main purpose of point is to get an estimation to measure your speed therefore you keep in mind the complexity of story (e.g, implementation time + team skills + knowledge + experience in the domain ,etc )
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're having trouble incorporating certain types of tasks into our product and sprint backlogs:
Meetings with clients
Training and knowledge-sharing
Administrative tasks
Some of these aren't directly related to the project, so it's easy to put them aside and refer to them as administrative overhead (thereby reducing the doable story points in a sprint).
Some tasks, however (usually client meetings) are recurring or very frequent. How should these be handled? They don't usually directly relate to any particular user story, but they're vital for the project.
In my opinion, "tasks" don't really belong to the Product Backlog, Product Backlog Items (PBI) should be used for things that are visible to the end users - or mandatory to achieve such items - and expressed in a way that demonstrate their business value.
Recurrent events like meetings, administrative tasks, etc don't really match this definition of a PBI and I wouldn't include them at the Product Backlog level. Actually, I don't see the point of tracking them at all (it sounds like useless overhead i.e. typically waste) and I would thus simply include them in the overall velocity. It just works.
Non recurring events, like a special meeting, R&D, exploration, etc don't really belong to the PB neither (how should a PO value them and prioritize them??) and I prefer to include their "cost" in the estimation of the related PBI. And when the item gets picked, we create a corresponding task in the Sprint Backlog, with a timeboxed estimation.
And we handle trainings like holidays. If a team member go to some training, it affects the team member allocation (e.g. 90%) and thus the overall team capacity calculated at the beginning of a Sprint. And we pick up less items.
Task is not related to product backlog. Task is related to sprint backlog. Activities you described are not tasks.
When we plan our next sprint we always reduce planned capacity by all holidays and trainings. We also reduce capacity by "administrative overhead". In our case administrative overhead is usually 1MD per team member per week. This overhead is for meetings and possilbe assistance in maintainance on already deployed projects.
Edit:
I think you should never create tasks for meetings, presentations, etc. in your spring backlog. Why? Because each task has some estimation wich affects current sprint. During sprint tasks are completed within real time and based on that burndown chart shows team progress in delivering customer value. What value will customer receive from meeting? Moreover such task is probably not related to concrete user story so what progress will be visible in product burndown chart? How you decide how many user stories should be taken for the next sprint when you have to count with value not included in their complexity (story points)?
Adding such dummy tasks (tasks with no added value) to your sprint backlog will also affect your velocity. It will look like each story point costs more than in reality because meetings time will be included in real work.
What type of meetings do you want to add to your sprint backlog? SCRUM needs only few meetings - daily meeting, planning meeting, review meeting, retrospective meeting and in larger project SCRUM of SCRUM. Daily meeting is so short that it doesn't have to be included in planning. Planning meeting, review meeting and retrospective meeting don't have to be included in sprint. SCRUM of SCRUM is specific and it doesn't affect whole team - can be reduced from planned capacity of attending members. No more meetings are needed. Most important: Communication needed for completing task is part of task estimate.
If you need other meetings simply reduce your capacity. If the customer, management or Product owner complain about small capacity simply explain them that it is because of non standard administrative or bureaucracy overhead.
On my last project we side stepped some activities in to our scrum board. They were not in the product backlog, but we invented them during our planning game.
The kind of activities we included was customer workshops, release activities, etc.
The reason we included them on our scrum board was to make it visible to anyone in the team what everyone else was doing, and in some cases also to assign the task to someone not in the middle of another critical task.
Typical recurrent tasks are absorbed by the estimation/velocity. Things like the stand up meeting, normal developer's interactions, pauses, etc...
For others events that are not related to building the product, I prefer to remove that time from the developer's availability to have the correct capacity.
So the number of user stories that we can plan depend on, their estimation, the team velocity and of course the capacity
My opinion is if these tasks are not directly related to a feature, like training, you should not include them in your product backlog, but rather adjust the available time from developers and consequently the velocity of your iterations. It is not because you have for instance a 40 hours working week that you can expect people to work 40 hours on projects.
If meetings or other non-development tasks are directly associated with achieving the objectives of the sprint\iteration\project then I have no problem including them the sprint backlog\iteration plan. If nothing else it helps to ensure that the tasks get done by raising their visibility.
If you don't include things that people need to do in your backlog, how would you propose to manage them?
Non-development initiatives take time, and they are just as important to delivering a quality product as dev and qa work.
You can choose to use a separate backlog for those items, or carry them in a separate project plan, but then you are working from two working backlogs, and sequencing and timing becomes an issue.
I typically force the teams to create stories for non-development activities like 'as a product manager, I need to produce a roadmap, or 'as a product manager, I need to setup technical workshops to review the backlog so that development teams can understand the features'.
it really depends on the situation, but if the backlog is THE central place to capture and manage work, why is it only Development and QA work that it gets used for?
There is no fix formula for deciding User Stories in Scrum. In my project, we pick and choose which work item should be converted to Stories. E.g. tasks like comparison of 2-3 IDE dev tools goes in a Backlog because it is directly related to development. But otherwise I plan for 5 hrs per day development activity for each team member so that they spend remaining hours in attending training, documentation, knowledge exchange, peer programming, etc. This works for me in justifying demo vs sprint velocity.
You can manage non-development tasks in a Trello board. These can be things like research activities or pulling data to be used for development. These don't belong in JIRA or Rally as they are not development tasks and do not have a story point estimation.
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 started a project that will be managed with Scrum/XP. We wrote the whole product backlog upfront for evaluation purposes. We're making sure all stories are customer-centric and we're evaluating them by
story business value: MoSCoW technique - Must, should, could, would/won't have this implemented
story effort/complexity (= story points): 1, 2, 3, 5, 8, 13, 21, 100 - related to story complexity/effort rather than ideal days duration
100 story points may have some stories with Would/Won't have because they actually are bigger complex stories that will be broken down later if needed.
Calculated story importance is based on value&effort by not overlapping MoSCoW stories.
But without 100 point stories our stories so far (also broken down) has complexity between 2 and 8 which we think is an appropriate story size to avoid micromanagement. But some stories became related or dependant on each other. We have stories that may take more if done first, and less if some other story would be done before them.
Questions
Is it possible to adjust story points later on during development, as we can do with story tasks where we can re-evaluate them, add new, remove existing or is this not the case with stories? Because changing their complexity, will also change end date estimates based on planned velocity. What's the best practice in this case?
You absolutely can estimate your stories again and you should. The points are only locked when the team commits to them at the Sprint Planning Session immediately prior to the start of a Sprint.
One practice I've used is when doing the individual Sprint Planning you should evaluate each story again. The team learns over time and will become more accurate with estimates and identifying dependencies. Remember what goes into a Sprint is up to the team, the product owner defines the overall backlog. If the project is time bound don't try to make the estimates fit the End Date, if you do you are setting yourself up for failure.
Remember that with Velocity you start with a guess at what you can accomplish. It usually isn't until the 3rd or 4th Sprint that you hit identify a realistic Velocity that the team can manage. Yes this does mean that you may have assumed the team could deliver 20 points per Sprint and actually can only do 15 points. Yes that means delivery time goes out or stories fall below the cut line.
As for dependent stories you should work with your product owner. If the team talks to them you can usually rearrange stories. Most people are receptive to someone that tells them "If we do A now it will take the full Sprint, but if we do A later it will take 15% of a Sprint" that makes it pretty convincing.
A useful practice to try is scheduling the stories within the Sprint. During the planning session once all stories are validated and discussed the team pulls up a calendar and discuss when they want to have things done. By putting target dates on a calendar it helps to identify overlaps and dependencies between the stories. This can identify things that are serial in nature and may cause a Sprint to fail.
Hope this information is helpful.
From your explanation you're doing a great job already. Of course there will always be stories with a dependency. Some may not even have directly visible customer value; i.e. the initial effort to set up an architecture and some frameworks). But if you leave them out you'll create a lot of technical debt. If you can, I'd suggest that you try to make the equation complete and somehow show the relation between the tasks.
For instance:
- task 3 is 8 points if done after task 2, but 12 points if done independently.
This way the product owner will feel the pain of ignoring dependencies, but can still make a choice to do the most valuable stories first. If the product owner is sure that all of the stories make it in the next sprints, then you can steer to have them implemented in the most efficient order. For instance, by blocking items for which dependencies have not been fulfilled (i.e. you can only have the 'change my logo on website' feature after the story 'webenabled version' is completed.)
Good luck!
I can only describe my expirience.
When we were planning first sprint we decided that we could accomplish 18 points. So we took several stories and total estimation were 15 points. As I mentioned above we were making our first steps in scrum and that's why we decided that 3 unused points and form-factor 0.6 guaranteed our success.
But our estimations of each story were only approximate. We had also some dependent stories. And we didn't make plan of implementation of each story because we thought that it's unnessecary with agile methodology.
As a result we failed our first sprint with only 8 complete points.
Before our second sprint I decided that we should take something from old good simple cascade and iterative methodoligies (and I was a scrum-master). So, on our next spring planning to make correct estimations we planned each story (about 20 minutes per story), with simple diagrams, all dependencies, details of implementation and so on. The planning was difficult and it took 2 meetings.
But the second sprint was much better and we've done almost all (actually we've done all but with some bugs). I think that we'll take less form-factor in 3rd sprint and it'll be successful.
There are some patterns that would help you in splitting User Stories in a way that they would remain INVEST, which means you would try to save dependencies, size, testability and value in particular. You can read more about that here: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard is actively applying and improving them, and he is not alone ;-)
Just be aware that splitting and keeping dependencies (which is like creating a critical path in a Gantt chart) is going to trump the capability of the team to be creative, and to negotiate on those stories, and might also hide a "non-valuable-proposition".
HTH
ANdreaT
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
During our iteration planning, we frequently find ourselves in the same position as this guy - How to estimate a programming task if you have no experience in it
I definitely agree with prototyping before you can give a reasonable estimate. But the same applies to anything that needs a bit of architecture and design - but I'm not that comfortable doing all this outwith the scope of a sprint.
The basic idea is that you identify as many tasks as you can that you're confident of, and estimate these as normal. For those areas that you're unsure of then there should be two 'types' of task identified: Investigation & Implementation.
Investigation tasks are brief descriptions of work that you're just unsure of, for example "Investigate how to bind Control X to data". An estimate is provided for these.
The Implementation task is a traditional rough guess, probably based on the story points assigned, of how long you think it would take to implement the feature.
During the sprint, when the investigation tasks have been completed, the developer should then be at a stage where they have a much better idea what is going on. 'Proper' Tasks can then be identified, which take the place of the Implementation placeholder. In addition, further Investigation tasks may be identified at this stage, and the cycle continues.
In the above example, we start with an Investigation task at 7 hours and an Implementation task estimated at 14. Once the first Investigation has been completed, Tasks 1, 2 and 3 will be identified and estimated with some degree of certainty, where Task 3 is another Investigation task from which Task 4 and 5 will be identified at a later stage. As you can see, the first Implementation estimate had delivery of the feature within 14 hours - but the reality is it took at least 4 + 7 + 3 + 4 + 2 = 20. A third more than the initial estimate.
alt text http://www.duncangunn.me.uk/myweb/images/estimate.png
All thoughts are welcome - my gut instinct is this will fly - am I right or am I the Wrong Brothers?
Cheers!
What we do.
Some features involve new technology. We can't accurately estimate them. Period.
We make up a number. Based on a couple of things. How hard does it "feel"? Can we get by with some kind of "partial" or "just-enough" implementation?
If it's hard, then it's hard. It will be expensive.
If there's a lot of parts, with a kernel of goodness and some bonus stuff layered on, we have a possibility of putting just the kernel into a release, and setting other stuff aside for later. A very few things are "all or nothing" where a partial release isn't possible. In that case, we have to provide enough time for "all", and that gets expensive.
Our standard approach is to get stuff that works, and possibly defer things to a later sprint if we ran of out time because of unexpected complexities.
What you're calling "investigation", we call technical spike sprints. For stuff that's new, we make up estimate number to placate managers who feel it necessary to overplan things. Then we spike the technology. Once it's spiked, we can revise the estimates based on what we now know.
Actually, the implementation of the feature took 27 hours - you forgot the first investigation of 7 hours, so in reality the actual implementation took almost twice as long as the estimate.
There are two ways you can go on this:
Just make the estimate as best you can and potentially experience a blowout in your sprint and a declined project velocity (you should only do this if the feature is both urgent and critical); or
Schedule the investigation for this sprint and leave the implementation for another sprint - without an idea of how long the task will take, the Product Owner does not have enough information to make a decision about in which sprint to schedule it or even whether to do it at all. Only tasks that have been estimated should be included in your sprint.
The first choice means your sprint and project estimates are somewhat arbitrary. The second choice gives much more predictability to your sprints.
In your example, the initial investigation may be scheduled for Sprint 1 but without knowledge of how long the task will take the Product Owner can't decide how to schedule it. If you came back with an estimate of 200 hours the Product Owner may decide not to do that feature at all, or to delay it until Release 2 of the product. The estimate comes in and the Product Owner schedules Task 1, Task 2 and the investigation of Task 3 for Sprint 2. After estimating Task 3, Tasks 4 and 5 can be scheduled in Sprint 3 or later.
Estimating feature usually is complex task. After some time your estimation will become better. But good approach can be that you estimate features with the story points. Story point is abstract value (meaning agreed among the team) that express complexity of the problem.
You should assign the same complexity (same number of story points) to the features of the similar complexity. Then later on it is enough to estimate only smaller set of features (or looking at the historical data) and you should be able to estimate how much time you need.
Features with the similar complexity need similar time effort for implementation.