Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm on a project right now that is using the scrum methodology with 2 week sprints. Here's what our team looks like:

  • 1 business analyst
  • 1 tester
  • 1 user experience designer
  • 2 developers (1 for the UI and 1 for the back-end processes)
  • 1 project manager

In a single sprint, we'll have 1 product backlog item (PBI) to design the UI for a page, another PBI to write the .Net code for the page, and 1 PBI to test the page.

How should these 3 product backlog items be scheduled so that they all get completed by the end of the sprint? Since they are all dependent on each other and require at least 3 members of the team to work together, it seems to me like they each need deadlines in order for them to get done in time.

The scrum master keeps saying that they don't need deadlines because the cross-functional team will take care of it. This hasn't worked in 10+ sprints, though.

Shouldn't the project manager be aware of this critical path and monitor its progress?

share|improve this question
    
Do you mean Sprint backlog items? I typically think of product backlog items as "Add feature X" (in terms a business user would understand, and then have a number of associated sprint backlog items ("create x screen", "create x backend job" etc). –  Brook Sep 20 '11 at 20:54
3  
"This hasn't worked in 10+ sprints, though" There's a myriad of reasons why the sprint doesn't get completed on time, but the most obvious one is simple, you put too much in it, your velocity estimate was overly optimistic. –  Brook Sep 20 '11 at 21:04

3 Answers 3

The first issue here is that the items in your backlog are not business-value driven. The UI alone doesn't provide any value, as well as the backend code alone neither does. I'd suggest you to try to slice the features vertically, this is, instead of thinking in terms of components, take the perspective of an end-user and redefine your items as user stories, e.g.

As a user I want to search by keyword so that I can find matches that are relevant to me.

Note that this feature may include several tasks: create/modify the UI, code the logic, fetch results from the database ... Testing is not treated as a separate feature, but included in each story, and based on your "definition of done", it will include several tasks, such as unit tests, automated functional tests, manual system tests, ... The purpose of working in short time-boxed sprints is to deliver working software regularly while still keeping the capacity to adapt to changes in the priorities. Untested software simply can't be considered working software.

It may happen that a story is just too big to fit in a single sprint. In that case you'll need to split it into smaller stories, again trying not to fall into a mechanical division per component when possible. Splitting user stories is not easy and it requires a great deal of practice. There are some nice articles on the topic.

On the other hand, agile teams are cross-functional. This doesn't mean that some people won't be more skilled than others in certain areas, but that members of the team collaborate with each other to reach a shared goal, this is, to complete the stories scheduled for the sprint. In the practice, this can translate to, for instance, developers assisting in testing tasks and vice-versa. Knowledge sharing (versus expertise silos) is a key practice for a team to get the most of him.

share|improve this answer

You don't follow Scrum because your 3 PBIs are not PBIs. It is one PBI. Also if you divide the PBI this way and have special role for each part you are not doing Scrum but ScrumFall. Your cross functionality doesn't work at all because you have separate role for each task so while one role is doing its part of PBI other roles are waiting.

Cross functionality means that almost every member in the team can do any task and it is one of core requirements to make Scrum work. Otherwise you cannot efficiently plan the sprint because you must count velocity per role and combine PBIs in the way to fill capacity of each member - that is mostly impossible.

share|improve this answer

How should these 3 product backlog items be scheduled so that they all get completed by the end of the sprint?

Daily conversation. It's called a "stand up". Everyone attends. Every day.

Since they are all dependent on each other and require at least 3 members of the team to work together, it seems to me like they each need deadlines in order for them to get done in time.

They don't need "deadlines". They need an ongoing conversation. Every day. It's called a "stand up". Everyone attends. Every day.

The scrum master keeps saying that they don't need deadlines because the cross-functional team will take care of it.

Correct.

This hasn't worked in 10+ sprints, though.

Wow. You people are obstinate. Do you actively hate each other? Or are people simply refusing to attend the daily stand-up?

share|improve this answer
    
+1 "Do you actively hate each other?" –  CaffGeek Sep 20 '11 at 21:00
    
hmmm... We're the first project in the company to use scrum so maybe we're not doing the daily meetings correctly. We have about 50 back log items per sprint and it really isn't obvious to see the dependencies. We're using TFS to store the items. Is there some kind of report that can show tasks in the order that they need to be completed? –  David Sep 20 '11 at 21:04
2  
"50 back log items per sprint"? What? 50 items in a 2-week sprint? How is this even possible? And how can you not coordinate this with daily meetings? What specific problems are you having that are not solve by actual conversations among the actual people who are actually supposed to be doing the work? –  S.Lott Sep 20 '11 at 21:06
    
Your question asked about 3 items, not 50. If you have 50 items in a sprint, that's a whole other problem. –  jhocking Sep 20 '11 at 21:20
1  
You need to calculate your sprint size not by the number of items, but by velocity and weighting the difficulty of each item. If you have 50 one hour tasks, then no problem. If you have 50 tasks, where most are 4-8 hours, it's an impossible feat. –  CaffGeek Sep 20 '11 at 21:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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