Delivering Business IT

Contact Us    fb in tweetGoogle

Scrum
UserStories (Requirements) Timeline Management Quality Strategy Build Environment Roles/Client Engagement Artefacts
User stories are small and minimal to fit into the sprint plan Project has to be estimated for timelines before the start date. All user stories are split into smaller sprints. A user story must include “Acceptance Criteria” that forms the basis for developing end to end test acceptance. Customized Product Owner
Scrum Master
Team Members		 User Story: User Story is the basic unit of requirements specifications for Scrum, and typically consists of a title and a brief, usually narrative, with a description of the desired system capability.
Scrum does not allow for changes once a sprint has begun. User stories can’t change in the middle of the sprint. Changes, if any, are accomadated in the subsequent sprints. Each sprint can have their own sprint planning. Sprint time is further divided into smaller chunks as Analysis, Development, Testing, etc.. Unit Testing   (4-9) Members in a team. Teams are split to multiple units for larger projects, aligned to core modules. Maintaining team collaboration is key. Teams meet everyday to review progress Product Backlog : The Product Backlog is the set of all un-implemented User Stories that have not been assigned to the current Sprint.
User Stories are selected for each sprint which form a duration of 2 to 5 weeks. Selection is also influenced by the need to release “working software” at the end of each sprint. Sprints are Timeboxed. Independent Testing:
(1) Test Case Execution & minimum documentation (Current Sprint)
(2) Test Case preparation (Subsequent Sprint)		   Customers participate via the role of a Product Owner, and join in atleast one or two daily team meetings a week. Sprint Backlog : Is the set of User Stories planned for implementation in a active Sprint
  Progress is measured based on the velocity of the sprint’s user stories Test Automation is optional, and is implemented only when regression testing is needed.     Sprint Burndown Chart: Is a visual resource effort burndown chart for Sprints (1…n)
  Sprint meetings are usually proportional to the Sprint duration. High priority user stories are tested first      
    Defects are raised and recorded and fixed in subsequent sprints      
    Performance & Security Validations are an end of the line activity.      
 
Kanban
User Stories (Requirements) Timeline Management Quality Strategy Build Environment Roles/Client Engagement Artefacts
User Stories in Kanban are assumptive relative to the Scrum model. Kanban is not a timeboxed environment. It has the continuous flow of items from one state to another. Unit Testing Customized No Prescribed Roles. Roles and participation are Similar to Scrum or XP, depending on the nature and size of the project. User Story Backlog
Kanban allows change to user stories at any time. Volume of items are regulated in each stage by placing upper limits. Independent Testing   (4-9) Members in a team. Teams are split to multiple units for larger projects, aligned to core modules. Maintaining team collaboration is key. Teams meet everyday to review progress Kanban Board: Is used for change management process and to track item movement stage.
In Kanban, user stories are considered as a task to be completed. A multi tasking limit can be set for each user, in every stage to manage the time and quality. Automation is optional and is required only when regression testing is needed     User Story Cards: Represent the Visual List of Items in progress.
  Progress is measured based on the cycle time. Test the high priority user stories first.      
    Defects should only be raised and recorded when they are not going to be fixed immediately      
 
XP
User Stories (Requirements) Timeline Management Quality Strategy Build Environment Roles/Client Engagement Artefacts
User stories are small in size and are less descriptive. A pre requisite is that Customers and Project Teams are very closely aligned with the vision of what is required. XP has short development cycles Test driven development. The first step is to quickly add a test, basically just enough code to fail. All subsequent updates to the functional code will pass the test cases progressively. If a test case for the released functional code fails, engineers update the functional code and retest. Continuous Integration Environment Customer,
Product manager or Product Owner,
Domain experts,
Technical specialists,
Interactions designers,
Programmers,
Designer and architects,
Testers,
Coaches- The Programmer Coach,
Project Manager		 Automated build artefacts repository system
XP allow changes, so user stories may change at any time before development start Development proceeds in very short iterations, typically 1-2 weeks in duration. Prior to each iteration features are broken down into very small stories. Stories are estimated by developers and then chosen by stakeholders based on their estimated cost and business value. Test Automation is mandatory   (4-6) members in a team is a good starting pointMaximum of 12 members in a team  
In XP user stories should be taken to fit for shorter period of one or two weeks long   Code Quality Verification is done with integrated automation tools.   Customer interacts with the team very frequently, owing to the assumptive nature of user stories and change dynamism.