Search code examples
project-managementscrum

SCRUM - Appropriate non-development resource level?


We are trying to run SCRUM for a small development team (three and a half developers) working on an on-line application and we are having trouble getting time from non-development resource e.g. product owner, user testing, etc.

I'm working on a business case for getting more non-development resource and for it to be more responsive to our requests for their involvement.

Current situation:

  • The product owner is a team of 5 people, half of whom are across the Atlantic from the development team (which is better than the previous situation where there was no owner at all)
  • The product owner "team" only meets, virtually, twice a month
  • There is no dedicated user testing or QA resource
  • The fastest time to complete user testing was 3 elapsed weeks, for about 2 man days of testing
  • We're working to a monthly sprint

Specific questions:

  • How much time per week should the product owner (if they were a single person) be spending on their product owner role?
  • Would you expect the product owner to be available "all day every day"?
  • How much dedicated testing/QA resource would you expect to be available per month?

I've tried Googling for "authoritative" answers, or just any reports on team resource levels, but have not been able to find anything.

Does anyone know of anything like this so my business case won't just be "I think...." but can have references to expert opinion and real world statistics?


Solution

  • How much time per week should the product owner (if they were a single person) be spending on their product owner role?

    I would say that about a day per week should be fine on average based on my experience with a team of 15 DEV+QA and one Product Owner. I would also strongly suggest following the proxy product owner approach, or create a requirements architect (google Dean Leffingwell requirements architect). This is in essence what we did, as our Product Owner didn't have the bandwidth to spend that time on the project.

    Would you expect the product owner to be available "all day every day"?

    of course thats the ideal. It also helps if there is a proxy that IS co-located. Without that, I would strongly urge to setup an SLA of time to answer questions related to current+next sprint via EMAIL. e.g. return by end of business day or something.

    How much dedicated testing/QA resource would you expect to be available per month?

    As answered above, it depends on the type of project and the amount of developers / BAs on the team. I would suggest having at least a 1:1 relation between BAs and testers, on the logic that the amount of QA required is a strong function of the amount of requirements specified. Since you are talking about an online application, I assume there isn't a very long regression/integration cycle, so a relation of 1:3 to developers can suffice. I see testers as an important influence on the requirements and usability not just bug fixing btw. Another factor is whether you intend to adopt Agile engineering practices e.g. TDD, Unit Testing, Continuous Integration, etc. If so, the testing resources will be much more focused on test definition, usability, performance/load testing, rather than regression.

    One way to see what is the bottleneck is to adopt some sort of Kanban board which visualizes the workflow. On that board you can see where the bottleneck is. Whether its in the PO stuff, development, or testing. If you are using a single scrum team with a regular Task Board Chart, you can easily get this information by adding a column for "In Testing" and "In specification" (so overall you have - Pending -> In specification -> In DEV Progress -> In Testing -> Pending PO Approval -> DONE). If you see that too many of your sticky notes are stuck in a certain column/stage, you know where to look for a problem. Show this to your management, its empiric and much better than any information/rules of thumb seen in other projects, or at least a very good complement to that...