How do you manage resources in an agile approach with PMI

Question

In a case with limited people like 5, you need to go through an iterative process.

If you weight, distribute and assign the stories to be developed in a way that everyone is orchestrated well and you go in a 2-week sprint and normally you go through the following "steps"

Sprint #1

Story #N

• Design
• Code
• Unit Test

After unit tests, one of your resources finished the last story from sprint while others don't and for some reason there is 1 day or 2 days left. This idle resource what is suppossed to do?

In traditional approaches as everything is sequential mostly everyone finishes at the specific date or late than planned. Also in traditional, you risk to do rework and re-plan again, but how to manage that idle resource in a sprint. How do you track or do with those excellent story makers who finished before time?

Answer 1

Generally speaking, there is always something for people to do. They can help a colleague with their tasks, learn a new trick, write some documentation, clean up some code, talk with some other team, prepare a presentation on some useful topic, get people coffee, talk to a product owner or stakeholder about goals, learn about some existing piece of product, clean the office, or do any other of the things that are on the "We really should fix that when get the time" list that every team has.

One of the key goals of being a self-organizing team is that people who have some left over time, will find something productive for themselves to do. If you don't see that happening, you might want to point them to some thing that can be done, but just let them pick something so they can learn to be proactive about these things.

Answer 2

@Erik's answer is perfect when the situation is that the entire team has finished the sprint goals early.

If only a few of the team members have finished early, their top priority should be helping other team members finish their sprint work. You want team members to be thinking team first not just about their individual accomplishments.

That having been said, I frequently observe developers saying they're "done" when in fact they're only code complete. Are there automated tests in place? Is the documentation done? Have you updated any relevant user guides? Do sales and marketing have what they need for the new feature? These things might be outside your "definition of done," but they are still important and will boost the quality of your team's deliverable.

Answer 3

During the sprint process, Sprint goal is the team goal. In my case we start every story using following sequence:

1. Developer and QA and Prod Owner (or BA) have a quick meeting to ensure they are on same page on with the story/acceptance criteria. (Saves us lot of rework)
2. Developer starts coding. QA person starts writing test cases (automated and manual) same time. They keep each other in loop through the sprint.

3. If they finish a story they move together to different story.

4. If anyone has idle time there is always plenty of activities like code review, test script review, build process optimizations, update documentation etc.

5. If there is still spare time, we look to pull in new stories OR we work in pairs (Pair programming)

Hope this helps.