First off, what is Agile/Scrum?

Agile is a term to describe the process of estimating and chunking out your designs into estimated user stories, and then having your scrum team complete these user stories in a two-week sprint.

​A sprint is generally two weeks, and a PI (or product increment) is generally 5 sprints, or 10 weeks. A PI will have a bunch of user stories completed within it that generally equal a feature or functionality for a product. The scrum team will story point the user stories so that the team has an idea of their level of efforts, and then estimate cost/staff needed accordingly. You can also read this cool resource from Atlassian regarding storypointing.

Okay, what is a scrum team?

A scrum team can consist of the following:
Scrum master: manages the project and scrum team.
Product owner: knows the business and/or product you're designing.
Business analyst: Assures all business rules and requirements are met in both design wires and code.
Developers: Write the code and often test it.
QA: Also known as quality assurance, will find any defects if something doesn't look or behave correctly.
​Analytics: Depending on the company or project, analytics leads can also contribute by tagging the new code.

Food for thought: Ways you can implement UX into the Agile process

If you're a designer in-house at a larger organization, you may encounter the agile process as your designs are being built. Often times, your business partners and IT take over once your prototypes are built. Here are some ways I have experienced "preparing a seat" for UX during the development process/sprinting.

• If you're observing the tasks being written during sprint planning, make sure a UX review is assigned to you (if it involves the look and feel). If you're using Rally, you can be assigned the task easily. Be clear about your review responsibilities if your company contracts or has a Quality Assurance service.
• Be sure to attend your sprint reviews; always know what is in queue for the next two-week sprint.
• Form relationships with your developers. After all, your final design is only as good as your coded product!

UX-Agile infusion: What I've found can be Improved from my experience

​This section is heavily dependent on your company's goals, UX culture, and even down to the scrum team.

• There should be a UX buffer time. If UX reviews are needed as an exit criteria/agreement for the user story, UX often gets the user stories too soon at the end of the sprint, not leaving enough time. 
• UX small fixes and visual bugs should not be saved until a future release. These can tax the user when all the visual bugs add up to a poor user experience. This includes equal importance on mobile and tablet if applicable.
• UX should be involved with the cost estimation process with Product Owners or Product Managers

 FYI, according to the Agile Manifesto, here are the principles followed:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity-the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• ​At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.