Your question is a little confusing because it asks how to do this in Agile Software Development but then asks for examples of items to check. The second question seems very specific to context and since you are already looking at OWASP documents, you probably have plenty of examples. I can help with the first, but before I do, a short caveat: there is no such thing as an Agile Software Development Process. Most people, when they say this, mean they have a development process built around the Scrum Framework, so I'll assume for this answer that this applies to your team. Even if it doesn't, most of the answers wouldn't change much.
To ensure the most secure application possible, here are a few things that typical Scrum teams do:
1) Exactly what you are doing - agree upon a security standard. This should be something that all team members agree to follow.
2) Scrum has something called a Definition of Done. It is a set of quality measures that every item must meet to be considered done in a Sprint. Compliance to the security standard should be on that list.
3) Like any quality concern, security is everyone's problem. People should be discussing it in code reviews, architecture reviews, etc and it should be worked into code analysis systems and deployment processes.
4) Separation of responsibilities (between people and roles) in certain areas can contribute to a higher level of security, but it can also cause problems. Allowing only one person to have an account to a server reduces a number of people to be compromised, but also creates a bottleneck. If that bottleneck becomes an impediment to business goals, people start looking for ways around it and that opens more security risks which are harder to manage because you don't know about them. In short, security that relies strictly on rigid control is often broken, but the problems are hidden.
5) Build quality (and security) in. Better than controls, build good habits in your teams. This can't be done with a policy, this is done with culture. Leaders have to encourage people not to cut corners to make deadlines. Leaders and influencers in the organization need to visibly show that it matters to them, then your engineers need to build a habit of working in a way that is more secure. This takes months, if not years, but the pay-off is immeasurable. If you succeed here, then anything you do "checking" for security risks only has to catch human error, which is far easier and a far smaller set of problems than human negligence or neglect.
