How to move a team from waterfall development model to scrum model ? What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether ?
First the team needs to want the change, and the business has to support it.
There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.
I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.
During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.
Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.
We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.
We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?
Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.
Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.
We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.
I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.
It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:
Outside the retrospective, the scrum master and product owner might want to think about a couple of things:
Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.
Given that the tasks in a specific sprint will not divide perfectly into the team, and all finish on the same date, what do you do to keep everyone working as the sprint moves into its final stages?
Inevitably it seems like there will be one or two people freed-up. If all the other tasks are done-done, and the remaining tasks are already underway, then what?
Do those team-members pick up items from the top of the product backlog, as they are likely to be needed in the next sprint anyways to get a head start?
What do you or your teams do?
While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.
First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).
Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.
As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.
Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.
Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.
Once you've gotten to this state, only then should you consider continuing on with the product backlog.
When using an agile methodology on a team programming project, what should be done when several people needs to work in something that is to be used by everyone. For example, There is a User entity, and two people have to do requirements that need to use that entity. So, first an skeleton is created and then the activities are assigned? or what is the procedure in these cases.
And second, Is it possible to find information that addresses this kind of issues that can occur when applying such methodologies?
The best thing about Scrum, is that it is an amazing tool for identifying bad practices. This is one of the cases. An agile team should be working with as many hands as possible, on the same requirement (requirement, feature, user story - same thing). The division of work between members should be based on the tasks needed to complete the requirement, no the requirements themselves.
Each task would be defined based on the modifications that need to be made to a certain component. Doing that will not only make the problem go away (nobody's working on the same code), but will unite the team members' efforts, and make them function as a real team, rather than a disparate group of individuals that happen to share a room and a manager.
As for official information on the subject, I can suggest reading any book about Scrum, but you might want to focus on the following sites:
A few great books:
And finally, if you pardon the shameless plug, you can check out my blog - I have a few posts on this subject (such as this one) and others from my experience about implementing agile methods in software teams.
Where can I find a practical example on how to use Bug, Risk, Scenario, Task and Quality of Service Requirement work items?
On MSDN documentation I found this topic: http://msdn.microsoft.com/en-us/library/bb668962.aspx but it is not enough for me to deeply understand when to use one or the other.
I don't think there is a single prescriptive way of using the work items. You have to adjust this to your own process and your own needs and primarily decide what you want to get out of TFS a this particular process template.
A good place to start might be the literature on agile methodology, for example: