By Andrew Witchger
- The daily stand ups are longer than 15 minutes. The idea of a daily stand up is for each team member to give a quick update about what they accomplished yesterday, what they hope to accomplish today, and any challenges they are facing in the development process. When the content of the meeting goes outside that scope, you’re wasting time that could have been spent on actual development.
- User stories are too vague or broad. The purpose of user stories is to break large project goals into small, manageable tasks by identifying a. the deliverable, b. which project stakeholder will benefit, and c. the business case. It’s fine to start with the big picture, but make sure you break them down into the smallest requirements possible before starting your first sprint. Not only will this keep your sprints from growing out of control, but more importantly, it will allow you to prioritize the issues with the greatest business value. For example, change “As a potential employee, I want to be able to send resumes to HR through the website” into “As a potential employee, I want to want to fill out an HR contact form on fhas.com/careers” and “As a potential employee, I want to be notified when I submit the form so I know it was sent.” If completing the story requires more than one team member or more than one day of work, then consider breaking it down into more manageable pieces.
- Changing scope mid-sprint. It’s important to adhere to the sprint-scope lockdown as much as possible. By trying to introduce changes during the sprint you will likely push back the next release, lose the current work in the sprint, and displace another important feature. The first question to ask when considering a change is “Can it wait?” If the answer is no, then before proceeding you need to be willing to scrap the current sprint and spend some time reevaluating the project priorities. More often than not, once the development loss is taken into account, even pressing issues can wait for the next sprint.
- You aren’t transparent with your scrum team. Agile development only works when you communicate openly about the amount of work you’ve completed, how quickly you completed it, and any help that you need from the rest of your team. If you withhold information, then you’re not just hurting the team and the project, but your own potential as well. This applies to the overall project goal as well. If you silo the needs, challenges, and goals of the project, then you’re missing out on the full business value of your developers. You never know when innovation will strike.
- You skip bug testing and QA. Are you willing to let your customers be your QA team? The amount of time and money spent in developing software won’t amount to anything if your product is more difficult to use than a competitor’s product. The risks involved with not including a solid QA team go beyond angering your customers; it can damage your company’s reputation as a software provider. While adding QA can be expensive, perfect development doesn’t exist, and sometimes pushing back your release date is the best option.