Omega Tech Development Model

Agile Scrum

Agile Model
*Image obtained from: http://www.zenqconnect.com/images/Agile-Scrum(new).png

Software Development Model
Omega Tech has chosen to use the Agile Scrum methodology for our software development model. This enables us to receive constant client feedback as well as be prepared for change, which is something that software teams typically struggle with in the traditional and linear models.

Product Backlog
Omega Tech will gather all necessary information regarding the project from the client. This information may be “fuzzy” or unclear at first and this is ok. The product backlog contains a large list of all the product features and requirements as they come from the client. These backlog items may be unclear as stated and this is fine, it is just somewhere to put all of the requirements as they come in. The product backlog will be ordered by descending priority.

Sprint Backlog
The sprint backlog is a backlog of tasks that are “sprint-ready”. What this means is that the tasks have all necessary information in order to develop and deliver the product. This includes clear functional requirements and a “definition of done” or “acceptance criteria”. The functional requirements are typically listed in short, bullet format and the definition of done is a clear statement about when the product is accepted as complete. This is usually able to be easily translated into a set of tests so that it is clear when the task is done. The sprint backlog is ordered by descending priority.

Sprint Planning
During a sprint planning meeting, you pull items from the top of the sprint backlog as a team. The amount of items needed to be pulled is selected as a team, and will more likely than not be a bad estimation for the amount of work the team can complete during the sprint. This will be the case for the first one or two sprints, but over time it is a good way to understand how much the team can complete during a sprint and will help us plan accordingly. We will know if we are on track or not and can more easily coordinate with the client.

  • When pulling an item from the sprint backlog, you must clearly define requirements in bullet format.
  • Initial estimates are a rough estimate of the complexity of the item and the team resources needed.

Begin Iteration

Write Stories & Scenarios
This is where we break the backlog item bullets into individual tasks by writing “user stories”. This is a short and simple definition of the feature told from the perspective of the person who desires the capability; being either a user of the product or the client.. (Example template: “As a <type of user>, I want <some goal> so that <some reason>.)

The user stories incorporate the “definition of done” through the way they are written so that it is clear when a task is completed.

Implement & Acceptance Testing
This is where the team lead delegates to the developers sprint items and the associated user stories.

Developers will implement the user stories and once all stories for the sprint item are complete and unit tested, then the item as a whole can be accepted as completed.

Deploy
The feature is “deployed”, in our case the feature will just be added to the overall software structure. Integration testing and component interface testing take place here if necessary.

Quality Assurance
This is where we thoroughly test the completed sprint item. Regression testing/etc. may or may not be done here depending on the item and if it calls for it.

More Development Needed?
After the QA process, it may be found that more development is needed.

  • If so, then the item may or may not be added back to the top of the sprint backlog. If the development is small enough that it can be completed by the end of the sprint without effecting the completion of other sprint items, then it may be done in the current sprint. If the item is still in the form of a “deliverable product” by the end of the sprint then it may be decided to add the newfound development needed on the item to the top of the sprint backlog.
  • If not, then we do overall system testing once again with each completed item and it is part of the deliverable product at the end of the sprint.

System Testing
Overall system testing will be completed once again to ensure dependability. During the last few sprints we will work with our clients and a set of beta testers that will be actual users of the system.

Product Release
At the end of each sprint, the idea is to have a “deliverable product” ready for the client. This, for example may be a version update of the product including a couple new features (this will most likely be the case).

Product Backlog Sprint Backlog Sprint Planning Begin Iteration Write Stories Implement and Accept Deploy Quality Assurance More Development System Testing Product Release