Success Tips for Agile Teams

We've been doing Scrum for few years now. I've also seen how our team and other teams do some of the common things which makes us less efficient. This post just talks about some of the things that I learned through Agile/Scrum training, Agile books, from our own experience and seeing/hearing other teams which do Scrum. Each point starts with what is good to do followed by (in brackets) how teams commonly do it now which makes it less efficient. Many of these were done by our team too, but we are trying to recognize the issues and improve them continuously.

1. Start with product vision and release objectives. Then do road map planning to define when each functionality is needed. It is important to share this with the team so that team understands the big picture and knows where they are heading to. (Some teams go from sprint to sprint heads down, which means the team may not understand the big picture.)
2. When release objectives are set, do release planning with the team and get commitment on what can realistically be delivered for the release. (Management could arrive at the deadline/feature list without consulting the team, which means it is not realistic. Having team commitment early on in the project is very important.)
   
3. Product owner should do continuous backlog grooming and thin slice the user stories with the help from the team. (Avoid having big stories which are not flushed out properly)
   
4. The focus of the sprint should be on maximizing delivering features which end users can use at the end of every sprint, even if it comes at a small cost of developer productivity. (The focus of the sprint should not be to manage the team's tasks and fully load the development team. Instead the focus should be on getting completely implemented user stories.)
5. The team should be well cross trained i.e anyone in the team should be able to take any tasks (as much as possible) to complete the sprint stories. For this to be successful, it is important to have a small team focused on a particular area. (Avoid having teams with too many specialists)
6. Team size including product owners and scrum master should be in single digit. (Think about breaking the team if your team size is in double digits)
   
7. Sprints should be sustainable with each sprint including review, retrospective and planning taking the same amount of time. (Many sprint teams are so tired at the end of long hard working sprint. The focus should be on making the sprints enjoyable and sustainable. Also, avoid having irregular sprint lengths)
   
8. The focus should be on conversation with product owners and recording the conversation as acceptance criteria for the story (confirmation), rather than writing long use case documents. This is based on famous three C's - Cards, Conversation and Confirmation. (Sprint teams should focus on face to face conversation rather than relying on long documents)
   
9. User stories should be accompanied with good acceptance criteria so that team understands what done really means for that user story. (Not doing this is the root cause of many bugs. Having good acceptance criteria and shared understanding (between product owner, developer and tester) of when a story is really done would help a lot)
   
10. Team should do collaborative planning and be empowered to do what it takes to deliver the sprint goals. Entire team should focus on how they can accomplish/commit to the sprint goals together. (Avoid too much focus on individual team member tasks. Instead focus should be on the delivering as a team)
    
11. Estimating user stories in story points is better than doing in hours. (This could be unclear if the team does not have common understanding on what a story point is. Entire team should have common understanding of what a story point is and understand they are relative estimates.)
    
12. When splitting user stories, try to split it vertically rather than horizontally i.e functionally rather than architecturally. (Developers have the natural tendency to break up a big user story into a) DB work b) DB API c) GUI work etc., Instead the user stories should be divided so that each user story delivers some meaningful functionality to the end user.)
    
13. Use daily meetings as a way to communicate to other team members. (Do not use it as a way to report individual progress, which over time might become mundane and not liked by everyone in the team).
    
14. Entire team should be committed to delivering the stories and delivering it completely. (Half/Almost done stories gives a false impression that they are done and also cause more bugs. Avoid it by not giving credit and don't use it's story points to count towards velocity.)
15. When the story is done, make sure it means it is both developed and tested completely (Often teams just do development and call it done, which means testing will be done later. This really means a story is not done, if testing finds major misunderstanding/bugs in the code)
    
16. Team should plan on getting the user stories implemented and give it to testers as early as possible in the sprint. (Often teams might finish a story very late in the sprint, which makes it hard for it be tested and fix bugs (found during testing) before the end of the sprint)
17. Developers could do code reviews, work on infrastructure tasks, help with testing, learn more about the product, etc., if they are done earlier than anticipated. (Often teams pack the sprint which mostly means there is no time to do anything else)
18. Use retrospectives efficiently to find and fix issues which slows down the team. Make progress on these issues transparent so that team can understand that their concerns are handled properly. Continuous improvement is important to any team. (Many teams use it as a formality and not really do anything with the issues raised in retrospectives. This could make retrospective meeting not liked by team members)

I just mentioned some of the things which came to my mind. Feel free to add your comments here.