I have struggled in the past adhering Agile into the software project mix for a long time, when i finally did “Life was so much easier” This read will expalin why.
We all know each project venture is unique and has diffent metrices and criteria that we have to meet but i think you can always squeeze in a Agile methodology to manage your team. What makes software development Agile is that value is delivered to the customer in small increments and continuously/frequently.
Scrum and Kanban are perhaps the best known of a number of Agile software development frameworks. So let’s focus on these two & a derived version of Scrumban.
All these methodologies aren’t prescriptive.
High-performing teams discover what works for them and flex the system appropriately. Team Size should be ideally 3–9 members.
This is the best cheatsheet i found on these,
Simply, if you can stick to a scope (a fix set of priorities) for two weeks and give a release to the client, integrating the functionality, completed within the two weeks, it is Scrum, but if the priorities/scope keep changing and have to provide release as soon as a task is done, it is Kanban.
In Scrum there is a case where the priorities doesn’t change but a lot of unplanned work comes in and the planned work cannot be completed in two weeks, then you have the flexibility to extend the sprint duration or move to Scrumban or Kanban. The risk of extending sprint duration may increase resource idling.
Since you guys can differentiate between the two, The following will contain both Scrum & Kanban elements :)
Note : The product backlog items can be written in User Stories or Use Cases, the difference? find out here.
Roles
- Scrum Master : one that should spend a fair amount of time collaborating and working with the team, is due to the following responsibility:
“A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.” — The Scrum Guide
- Agile Coach : Agile coaches usually get a wider mandate and hence are able to better foster overall organizational growth. Also, Agile Coaches could potentially coach more than Scrum.
An Agile Coach works with ALL teams, AND executives AND other
teams/groups.
A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way. An Agile Coach helps to define what is to be done, how, who does it, when, why, how it fits in with the organization, change management, people management and interactions between agile teams and other parts of the organization (like Dev Ops, Hosting, Build teams, Education, UX/UI, etc).
The main difference between Agile Coach & Scrum Master is the level that the two are operating, single team or enterprise.
- Product Owner : one that decides what to build, their job is to take input from customers and from various Stakeholders and organise it into a prioritised list of features and User Stories. The list is known as the Product Backlog.
“Ensuring that the Product Backlog is visible, transparent, and clear to all” — The Scrum Guide
- Development Team : who is responsible for the state of the Sprint Backlog:
“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.” — The Scrum Guide
Artifacts
- Product Vision: According to VP, “The Product Vision is an artifact to define the long-term goal of the project/product. It sets the overall direction and guides the Team. Everyone should be able to memorize the Product Vision; therefore it must be short and precise.”
- Sprint Goal (Scrum Only): According to VP, “This helps to focus the Sprint. It is the objective that will be met within the Sprint through the implementation of the forecasted Product Backlog items, and it provides guidance to the Development Team on why it is building the Product Increment.
As per the Scrum Guide, the responsibility for crafting a Sprint Goal is for the Scrum Team. It is however in large part of interest to the Product Owner to support this process by having clear business goals for the coming Sprint, which can also make ordering the Product Backlog a lot easier by providing Focus.” - Product Backlog: The prioritised list of features, functions, requirements, enhancements, fixes and User Stories. Do not assign cards to the team when it is in this. It should be moved to “in development”
- Sprint Backlog (Scrum Only): Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Dev Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
- Definition of Done / Increment : This drives the quality of work and used to assess when a User Story has been completed according to its acceptance criteria.
- Burndown Chart : It is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current sprint. Since im using free software, i used this : Scrumage.(It has a free downloadable excel version that comes in handy.)
Ceremonies
1. Sprint Planning (2hrs for 2week sprints):
Driven by the Scrum Master, Product Owner and the Development Team participates. Together they select high priority items from the Product Backlog that the Development Team believe can commit to delivering in a single Sprint.
Be sure to keep in mind any time off, vacations, holidays, or other scheduling details during the sprint to accurately reflect the amount of work that can be accomplished.Try not to get sidetracked by items that haven’t been determined ready by the Product Owner, after all It’s a Sprint! It’s important that we have the Team Velocity(explained below)as well.
Process : A card is selected from the Product Backlog and the team plays Scrum Poker!
Scrum poker or planning poker is a consensus based, gamified technique to estimate the complexity and effort of a software feature. After presenting the feature, each member of the team picks a vote from different ranges of card sets. The vote remains hidden until all members have voted to avoid influence from other team members. After everyone has voted the highest and lowest estimates explain their choice and the process is repeated until the team agrees on a value.
Here relative estimations(Story Points)are given rather that absolute estimations, why? People are naturally better at relative estimations, it rectifies false assumptions|Relative estimation takes less time and is easy to refine|Its geared to be more team centric than time centric|Its not by units of time, but rather by how items are similar to each other in terms of complexity.
Story points usually follows the Fibonacci sequence: 1,2,3,5,8,13,21
1 Story Point could represent a range of 4–12 hrs, 2 Story Points 10–20 hrs (If you are wondering, yes this includes QA and everything related to a particular task defined in Acceptance Criteria)
2. Daily Standup (15min):
The Daily Standup is the team’s chance to get together, define a plan for the day’s work, and identify any blockers. The Scrum Master, Product Owner and the Development Team.
Note : Stick to fixed start time everyday and timebox it! When something comes up in this meeting that needs a longer conversation, encourage the team members to sync up as soon as the Daily Scrum wraps up.
3. Sprint Review (1hr for 2week sprints):
This is a demonstration of new functionality to Stakeholders. Most importantly, all of the work showcased during this time should be fully demonstrable and meet the definition of done. Actionable feedback received during the Sprint Review should be converted into new product backlog items for later prioritization and discussion.
4. Sprint Retrospective (2hrs for 2week sprints),
This is a review of what went well, what went badly and what could be improved. The aim of the Retrospective is to ensure that the next sprint is more efficient and effective than the last. Here the burndown chart is shared with the team and the sprint velocity is determined.
- The Sprint Velocity,
Ex : Sprint 1 Completed Story Points — 20 (Velocity is 20),
Sprint 2 Completed Story Points — 35 (Velocity is [20+35]/2 = 27.5), Sprint 3 Completed Story Points — 38 (Velocity is [20+35+31]/3 = 28.6)
Velocity is a great at-a-glance measure of a team’s performance but don’t make velocity your goal, there is a lot riding apart from that.
Create a space where the conversation flows easily. Consider bringing in food, colored markers, sticky notes and other things to encourage participation.
3 Sticky notes are given to each member and told to list down What he/she 1.Liked 2.Thinks lacked 3.Learned in the Sprint. These are pasted on a board organized to these sections and discussed. Any actionable item should be converted into a new backlog item for later prioritization and discussion.
5. Sprint/Product Backlog Refinement
Scrum teams do this in the Sprint Planning itself but some teams do it seperately. This is the act of adding detail, and an order to the items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. This helps the sprint planning to go smoothly. In Kanban this meeting is essential to add estimates.
Note : The older items which are sitting maybe over few months can be moved to a different backlog board after a discussion to enhance focus on priorities.
In this meeting User Stories/Backlog Items are broken down further to make them managable, they have to be broken down vertically instead of horizontally, why? According to Christiaan “Horizontal break-down is often accompanied by ‘silo thinking’. Every member is taken from one of the silos required for software development. The ‘design guy’ will take care of design, the ‘database guy’ will set up the database, the ‘developer’ writes the code and the ‘tester’ does the testing. If team members are not interchangeable (which is often the case when using this approach) there is a good chance of bottlenecks.” Horizontal slices can’t be prioritized since they are fairly technical, which creates distance and misunderstanding between the Product Owner and the team.
If Product Backlog Item’s are broken down vertically, they are broken down in such a way that smaller items still result in working, demonstrable, software. Functionality will not be split across technical layers or tasks, but across functional layers.
See the cheatsheet below,
Software
There are lot of ways to tackle backlogs using Software, the most popular of all is Jira. I agree its pretty easy and has all the functionality, since im managing a lot of projects including very less funded products, i have to use free software, Hence the following,
ClickUp, MeisterTask, TeamWeek, Trello(What I Use), Wrike, Bitrix24, Teamwork Projects, Asana… etc
You can view a sample trello board here
Burndown Chart Excel Version
Give me a clap, if you find this interesting :) or maybe drop a comment if you find this contradicting.
