Excira’s primary development methodology is Scrum. Scrum is a popular agile development process emphasizing short development time boxed iterations or “sprints” of 2-4 weeks, small self-directed teams (less that 10 members) and daily team assessment.
One of Scrum's values is courage, courage by management to let the scrum team self organize to achieve the requirments of the sprint, and courage by the srum team to accept the responsibility and to self manage. (Turn te volume down if you are at work!) Scrum Roles
Scrum defines 3 roles, a product owner, a scrum master, and scrum team members
Product Owner For our engagements, the client provides the product owner. The product owner is responsible for providing and prioritizing the product requirements. The product owner need not write detailed requirements and use cases them selves, but is available to interact with the scrum team who generates these artifacts. The product owner needs to be easily accessible to quickly answer questions about requirements as they arise
Scrum Team The scrum team develops the product. Scrum intentionally does not differentiate between “requirements analyst” “developer”, ‘architect”, “tester” and so on. Each team member works across disciplines according to the team need and their capability. Scrum team members may be come from the client staff as well as the Excira’s consulting staff.
Scrum Master Scrum master is part developer part manager. Their role is to communicate and reinforce the project goals and vision, reinforce the scrum values and to “keep the developers developing”. The scrum master’s main job is to remove impediments to developer productivity encountered during the project. The scrum master runs the daily scrum, the sprint review, and mediates between management and the scrum team. Either Excira or the client may contribute the scrum master to the project.
Scrum Artifacts
Scrum is light on artifacts specifying only three, the product backlog, the sprint backlog and the sprint burn down chart. Other artifacts may be added as deemed necessary by the scrum team depending on the size, complexity and risk of the project.
Product Backlog The product backlog is a prioritized list of the features, use cases, scenarios, defects, to implement or fix in the product.. The product backlog is created and maintained by the product owner.
Sprint Backlog The sprint backlog is a list of features use cases, scenarios, and defects to be fixed in a given sprint, and the tasks necessary to implement them. Tasks are kept small (in the 4 –16 hour range) and are tracked daily in the daily scrum meeting. The at the beginning of a sprint the product owner decides what features to build on the sprint based on the estimated effort of the features, the development speed of the team, and the risk or architectural impact of the features.
Sprint Burn Down Chart As the sprint progresses the team re-estimates the remaining time for each task in the sprint. And the total remaining estimated effort is graphed daily. This should tend to zero as the project reaches its completion deadline. Tracking in this way gives an early indication if sum functionally must be dropped in order to complete the sprint on time.
Scrum Activities
Pre-Game Planning During pre-game planning stakeholders contribute to the list of features, enhancements and so on to develop the product backlog. Enough work for the first sprint and probably much more is outlined.
Sprint Planning I Before each sprint two sprint planning sessions are held, during the first the product stakeholders refine and prioritize the product backlog, deciding the goals for implementing in the next iteration using rough sizing and risk information provided by the scrum team.
Sprint Planning II The product owner and scrum team meet to try to determine how the requested goals can be met. A sprint backlog is created listing more detailed tasks and finer estimates of each feature. If the requested goals can not be met with the given resources this information is communicated to stakeholders who may increase resources or remove goals from the iteration or both and the meeting is held again. If the estimated effort matches the resources available, the scrum team commits to the sprint goals.
Sprint This where the actual development is done, sprints are typically in the 2 to 4 week range depending on the size and complexity of the project. Each sprint results in production quality software that implements the features in the sprint backlog.
Daily Scrum The daily scrum meeting is a short (15-20 minutes) standup meeting where the scrum team members communicate the status of the project to them selves and any one else who cares to listen. The sprint burn down chart showing the updated remaining estimate of sprint tasks is updated prior to the scrum and is presented during the scrum.
During the daily scrum, each team member answers 3 to 5 questions:
What did you do since the last scrum?
What do plan to do before the next scrum? Here team members volunteer for the next remaining tasks
What impediments do you have to your progress? The scrum master records impediments and endeavors to have them removed before the next scrum meeting.
Are there any new tasks you discovered?
Did you learn anything you wish to share?
Sprint Review At the completion of the sprint a sprint review is held and the completed software is demonstrated to the product owner and stakeholders. Feedback and product brainstorming for the future development is done but no commitments are made. Any suggestions are recorded in the product backlog and reviewed at the next set of sprint planning meetings.
