Agile they said. Embrace changes they said. Agile development conquered the world of SLDC. More than 80% of the softwares being developed via agile methodologies nowadays.
What is Agile?
Agile focus on releasing urgent solutions required to the client in a faster manner. Minimal documentation practice needs to be adapted and team members needs to be efficient on what they are doing for achieve success in this agile earth. There is no time to redo. Verbal communication is more acceptable over rather than bulk texts.
Why Agile?
See this, my first post to the internet 🙂 was about agile.
- Lean and Fast
- Better Visibility
- Better Prioritization
- Less downtime bow tasks
- Improved Teamwork
- More Predictability
Types of Agile Programming
Two main types of Agile are Scrum and Kanban.
Kanban
Kanban is when a work/task has no deadlines. A Kanban team focus more on the quality behalf of the quantity. Typically repeating tasks are managed with Kanban.
- Usually support and service teams.
- They to repeated tasks.
- No deadlines.
- No plan mode, no sprints.
Scrum
Scrum is when a team need to work actively on set of requirements to meet a deadline. We cannot say that scrum team is focus more on quantity than quality. Scrum team has there own set of engineering best practices to follow on achieving the desirable quality.
- Teams with target deadlines.
- Organize your prioritized list in batch called Sprints.
Scrum Team
Scrum Team are usually with 5-9 members.
A typically team would be,
- A Business Owner(BO)
- A Business Analyst(BA)
- A Scrum Master(PM)
- A DBA if required.
- No of developers (2-5)
- No of QA(1 or 2)
A scrum begins when the BA start asking or collecting User Stories from the BO or other fact finding techniques. Note here that no heavy Business Requirement Document(BRD) is made.
User Stories
User stories are Requirements. Each and every requirement within the business system is known as User Stories.User stories are listed or organized in backlogs. From backlogs put into a sprint based on priority.
MoSCoW Prioritization
- Must Have – No point in delivering the project without these stories.
- Should Have – May be less number of people or functions get effect if nor included.
- Could Have – Less important but wanted.
- Won’t Have this time – Skipped for next sprint or version.
See more about MoSCoW here :https://www.agilebusiness.org/content/moscow-prioritisation-0
Story Points
Are used within scrum to measure difficulty or workload of the individual ticket.
This is used instead of hours measuring project for team members to estimate for how long a task will take.
The idea of being an individual should only be assigned x-number of story points within a specific sprint to prevent overload.
Story Points helps to identify and specify hardness of a work, also to avoid hour measurement for a work.
Although not nice better to have story points mapping to the hours to track half a day work and a full day work.
Example :
- 30mins = 1 Story Point(SP)
- 1hr = 2 sp
- 2 hr = 4 sp
- 4 hr = 8 sp
- 1 day = 16 sp
- 2 days = 32 sp
- 3 days = 48 sp
User Stories placed in the Backlog.
A Backlog
The backlog contains all User Stories that will be put into development soon.
An Epic
More like a theme how a collection of works done. Something like a Tag for task/s. Mostly modules of the application; like ‘Miscellaneous’, ‘Usability’, ‘Controls’, ‘Change Management’, etc.
Sprint Plan Meeting
Held after backlog is being created and before starting a Sprint. Entire team will participate and build a strategy. Strategy is based on “How we gonna develop?” , “How we gonna Test?” and “What we going to Document”. In addition to strategy planning important dates are decided; such as integration dates, testing dates, and deadline.
Without writing BRD or FRD this sprint plan meeting serves as the orientation for all the members of the team. Typically half a day. can be extended to one day if required.
So what is a Sprint?
A SPRINT
Nothing but a measure of time. usually month or less but consistent. In which chunk of works done against the product. Two week sprint is a pretty good standard.
A project manager or scrum master will perform an action called Sprint Planning.
Sprint Planning
The first step in Sprint Planning involves placing specific Tasks. User Stories can be modularized further into Tasks with high cohesion and loose coupling.
Task
The idea being that the larger Task is much easier to perform when split into smaller Tickets to be placed within the iteration(aka Sprint) or set of User Stories which would be assigned to a Scrum Team . Swim lanes(something like a Gantt Chart) are a great tool to categorize different tickets in different areas/categories.
This milestone is a small goal for team members to shoot for.This makes the overall project to be completed much less daunting and easiest to digest, so to speak.
The next step in Sprint Planning and releasing software properly is creation of a proper Scrum Board.
The Scrum Board
Scrumboard is like a digital-visual representation of a cork board or a physical planning board teams use.
The idea behind Scrum Boards are,
- To have a main source of information that is easily digestible by team members
- And communicates the current progress, delays and individual tasks in a central location.
Every development team works a bit different.
A board is usually split into three very basic categories/buckets.
To do, in progress, and done.
As you are most likely already aware, the categories are directly connected to the specific statuses contained within the project’s workflows.
So tickets within specific individual statuses are dropped into these buckets known as categories.
Subtasks do not count as individual tickets within sprint planning.
When creating a sprint, The time period should not change between sprints.
Daily Scrum Meeting
Every morning scrum team has a scrum meeting. Each one says about,
- What are they doing?
- Accomplishment
- Plans
- Inputs
- Issues
If any issues identified project manager, business analyst , and business owner set into a quick meeting while others carry on with the sprint.
When pushing more tasks/issues to a running/planned Sprint, pull down the same story points to balance the sprint. Else you will not be able to complete the sprint on deadline
At the end of each sprint developers and operations teams (DevOps) comes together they branch the newly created code, merge it to the original source, quickly performs an integration testing, and deploy.