Corporate Education Group

C O R P O R AT E E D U C AT I O N G R O U P Story Writing Practices Here are some suggestions for finding and writing good user stories: • Identify different user roles • Brainstorm user stories for each identified user role • Build a low fidelity throw-away prototype to help users visualize what they are looking for • Write a story for each needed feature; break epics up if possi- ble but do not spend too much time on this activity yet Role of the Product Owner The product owner is the key stakeholder—he or she knows what the product must deliver. This role should be fulfilled by someone from the business, but could also be a business analyst as a product owner proxy. The product owner must be present to answer ques- tions from the development team during the project. If a product owner or a SME is not available, the business analyst is expected to bridge the gap. This may require additional documentation to re- duce the risk of the project be- cause of the frequent unavailability of the product owner. Change Management Any new or changed requirements are simply added to the product backlog at any time. The iteration (sprint) goals however remain untouched. The team manager (scrum master) protects the team from changing sprint goals, but the organization can abort a sprint at any time to refocus the team on a new, higher priority set of goals. The product backlog is intention- ally dynamic: there are no frozen requirements. Product Backlog The product backlog is a collection of estimated user stories that have not yet been implemented. The backlog also contains constraints and bugs. The total effort for the project is the sum of all story points. Story points are assigned by the implementation team, and are a measure of the story's overall complexity and required level of effort. They are generally not person hours, but rather a number between 1 and 10, where 1 is an easy to implement story while 10 is a very difficult story requiring lots of work. Note that agile teams do not attempt to estimate the effort required for a story up front. Instead the project schedule is derived through observation. Schedule Estimation Scheduling in agile projects is empirical, i.e., it is based on actual measurements rather than models or guesses. A common method for deriving schedules is the following: • Observe the actual number of story points implemented during a sprint: this is the teams rate of productivity or velocity • Divide total number of unim- plemented story points by the velocity to get number of sprints needed to implement the entire backlog • Multiply number of sprints by the sprint length to get the num- ber of calendar days needed to complete the project's scope How Does Velocity Change? Velocity decreases when: • People are removed from the team • People have external assignments • Sprints are frequently aborted • Product owner is unavailable • Scrum master does not remove obstacles Velocity increases when: • Infrastructure has been substan- tially built out • Team becomes more familiar with domain • Team has competent members Agile Success Criteria Agile methods are successful when the right conditions are in place. Open communication and trans- parency are two of the most crit- ical success criteria. For example, anyone can come to daily scrums and sprint review sessions. The backlog is openly viewable. It is also very important that there is a certain level of commitment by the organization to let the team work and not fear "punishment" when an iteration had to reduce scope because the team commit- ted to too many features. For more information on this topic, as well as how Corporate Education Group can help optimize your organization's performance, contact us or call 1.800.288.7246 (US only) or +1.978.649.8200.

• Cover