Lets say team works 5 days, and there are 3 developers in team, and they are working 8 hours per day. So actually it is easy to calculate : 5*3*8= 120 hours of work for per week.

But there is something missing : there is no time for testing and code review process at the last day of sprint. Because it takes some time to test sprint items and friday night (last day of sprint) works cannot be send to done.

So for agile prenciples, how should i calculate sprint capacity? should i estimate it for 4 days ? if so, what should developer do in last day ?

up vote 9 down vote accepted

It is a common agile practice to reason in terms of story points instead of hours. You can learn more about why we do so here.

The velocity concept, instead, is well explained in this blog post.

I don't want to complicate things, so I will answer to your question speaking in terms of hours.

Let's imagine that you are on the first iteration with a brand new team.

In such a case, you can assume that the team will be "really" working for about 70% of their available time. You are considering the fact that the remaining 30% will be taken up by other tasks not related with development (paperwork, e-mails, phone calls, etc.).

It is wise to start with a conservative estimate. The idea is to adjust your estimation in the next iteration and use it to determine how many hours of work can go in the next sprint.

Let's give a look at your example (a team with 3 developers, working 5 days per week, at 8 hours a day):

3 (number of developers) * 5 (days) * 8 (available working hours per day) * 0.7 (initial estimation) = 84 ("real" working hours that your team can handle in one week)

Based on your question, I think that it could be good for you to search more information about the concept of Definition of Done (DoD) as well. You can start from here.

I understand that in your organization testing is separate from development. This is not the best agile approach, but it is (sigh!) common. You can find some interesting information in this answer to the question "How to fit testing in Scrum sprints and how to write user stories in Scrum" on Programmers Stack Exchange. Give a look also at this blog post about testers working in an agile team.

It is complicated to tell you what is best for your team and organization based only on the information provided. My understanding is that you are working with one-week sprints. You wrote that, according to your experience, it is better to leave the last day for testers to do their job. In this case, if I were you, I would probably continue to consider 5 working days. The team needs to speak with the Product Owner and organize the Sprint Backlog to have user stories that fit into 4 working days to be done (so that they can be sent to the testers team in the same iteration) plus another story (or more) that can be done in the last day (to be sent to testers in the next iteration).

  • Great answer, but the amount of bold is really hurting your message. Please consider using less of it! – dpollitt Feb 24 '16 at 14:48
  • Seems like what you are adding/mentioning as Initial Estimation (0.7), it really is the Focus Factor. – eMdOS Feb 21 at 23:46

I think Waterfall / Agile methodologies are being confused here. Testing should be completed after each user story is completed and not on a specific day of the week. This sounds more like the Waterfall methodology.

If there are elements that are less important the product backlog should be groomed and prioritised by the end user.

I'm sorry I would have posted this as a comment but I do not have enough reputation on this site yet. I have quite a bit of experience and academic qualifications here and will only be too glad to help or offer ideas.

There is a contradiction here, you don't use hours in terms of velocity. When you are estimating stories they should be done in terms of story points. These are typically Fibonacci numbers and stories should be sized to take into account effort to do, testing time, testing complexity, risks, unknowns etc.

So you could have a story where development may only take a few hours, acceptance criteria is clear, tests are straight forward. You'd probably say that was a 3 point story.

You could also have a story that ideally would take the same time to code, but the requirements/acceptance criteria is more hazy, to setup tests may take the tester several hours of prep, the story is touching something where you know there is a lot of technical debt (or has poor test coverage), so although ideally it'll take the same time, there are a number of risks, so you may decide to make this an 8 or even a 13.

Now based on this you can look at what the team did last sprint and estimate your capacity based on that. So if the team did 100 points and it is the same team, and the technical risk hasn't changed (say by working on some unknown area of the code), you would plan based on that figure, not hours.

This covers all your missed areas and leaves contingency for ceremonies and problems as you'll gain and lose over the sprint.

First of all, you have to calculate your team velocity - in others words how much they can do in one sprint (including concept, development, test and meetings). Then you will be able to know how much time you need to save for things other than coding.

In other words - no you don't have to cut your development phase to 4 days, you simply have to realize that testing will be done on first, second and ... day, so add hour or so to task based on it's complexity. That will let you complete sprint without saving time for one big testing at the end.

Determine your scrum team's total working hours for the sprint, then subtract 1-2 hours per person to absorb the unknown (slack) and the remaining hours are your team's capacity (how many hours of work they can complete in a sprint). Here's an article that I wrote that should help.

http://bit.ly/1L3AkZm

I'd like to hear more about the project itself. Are there external vs. internal clients, how are the project constraints prioritized (note: quality should never be compromised), is there one product or multiple products in play, what are those products, what does the software implementation process look like, etc. But, given what we have, here are some things to consider.

  1. Estimates should always come from the team (ie the people doing the work).

  2. In order to provide accurate estimates, teams must be able to focus on the work. If they are getting sidetracked by support requests, unnecessary meetings, etc., it is difficult to get an accurate team velocity and therefore provide meaningful estimates. Do what you can to ensure the team can focus. If you are not the scrum master, team up with this person to ensure the team is performing as well as possible.

  3. If you have external clients, it is a historical norm for them to want an hour-based estimate. Ideally, you would structure contracts & expectations in a way that did not rely on hours-based estimates. However, if you are in the middle of a project and need hourly estimates, it is ideal to let the client/business stakeholder know that the best estimates will come during sprint planning, and that estimates further out should be expected to change. Given all that, you could derive hourly estimates by executing sprint planning as follows:

    a. During backlog grooming, discuss & document the various tasks needed to complete (according to the def of done) a user story & have the team assign story point estimates to each story. Tasks should include devops/setup, development, code review. Update estimates as they come in and provide to clients/business stakeholders.

    b. During sprint planning, have team confirm tasks & story point estimates for each user story in the sprint. Then, assign the owner of each story as the person doing the dev. The story owner will also be responsible for managing the story's code review process. If possible, assign all tasks, for each sprint story, to an individual.

    c. Have each developer go through each task assigned to them and assign an hourly estimate. This can be during, or outside of, a sprint planning meeting. At the beginning of a project, it may be helpful to review the hourly estimates as a group, perhaps in a follow-up sprint planning meeting (ie sp meeting 2).

    d. As the project progresses, assuming everyone is following Scrum rules, you should be able to clarify team velocity, and then correlate an "hour-of-work per story point" estimate for your business stakeholders, allowing you to perform hour-based capacity planning.

  4. If you have a little extra development capacity at the end of a sprint, you could look to have the developer w/ extra capacity do some of the following:

    a. do some pair programming with one of the other developers. this could reduce bugs/speed the code review process, as well as provide an opportunity for peer mentoring.

    b. document any development-specific items that can be re-used on future projects, or could be used to help troubleshoot software issues in the future. another possibility would be documenting & sharing any lessons learned that could be shared with developers on other teams

    c. volunteer!

    d. mentor other developers

    e. look for opportunities to streamline devops processes

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.