Agile software development -Scrum for developers

Scrum is one of the most widely adopted Agile frameworks used by organizations to deliver high quality products to their customers faster and more often. Combining Scrum with Software tools like JIRA and Confluence can take your organization agility to another level. The beauty of Scrum lies in its simplicity. It's emphasis on transparency, inspection and adaptation leads to continuous improvement and effective team work.

Scrum Roles

Scrum has 3 Roles.

Product owner
Scrum master
Development team member

All three together form a scrum team.

Product Owner (PO):

• PO is accountable for product backlog which is the to-do list of items for the development team. Product backlog is the list of features, enhancements, defects and any kind of action items for the scrum teams but more specifically the development team. The PO owns the product backlog. Scrum does not prohibit anyone from making changes to product backlog but PO is eventually responsible for the contents as well as the order of the items in the product backlog.
• PO is responsible for making sure that the development team works on most important product backlog items. 
• PO is a person and not a committee. Scrum enforces this rule to avoid conflicts that arise out of differences in opinion in a group of people. This does not mean that PO is the only person to have opinion on order in which backlog can be implemented. PO can be influenced by members from within or outside the scrum team. But PO has the final say on order of backlog items. This makes PO role extremely challenging. The PO shouldn't be confused with Project manager or product manager.

Characteristics of PO

• Visionary
• Understands the needs of business community.
• Domain expert - Understands the impact of IT on organizational transformation.
• Competitor roadmap - Understands how competitors manage their business and their customers.
• Good communicator - He/She should convince technical and business teams to align on the same goals.

Technical expertise of PO

• Need to understand technology just enough so that they can make intelligent decisions about it as well as communicate effectively with development team
• Senior business analysts with good domain knowledge generally make good PO's but there are always exceptions. People from any field with these characteristics could really make good PO's.

Product Owner != Project Manager

• Scrum does not have a Project Manager role.
• Organizations implementing scrum will most likely will have Project managers and they have an important role to play but Project managers are not part of scrum team.

The Development Team:

• Just like PO decides what needs to be built, the development team defines how it will be built. Scrum execution means converting the subset of product backlog items into potentially releasable increment. In simple words potentially releasable increment is a functional software that can be released to the user community, This is what the development team builts. 
• The development team should not be confused with group of programmers. The team include individuals with one or more skills in multiple areas such as design, coding, testing, documentation, deployment, process automations etc.
• Two key characteristics of development team are that they are self-organized and cross-functional. Self-organized means the team knows how to do their job with minimal outside input. A Self-organized team has to be cross-functional. It means they should have all the skills needed to convert a set of product backlog items into a potentially releasable product increment that is functional software.
• There are no sub teams and no hierarchy within the development team. For example the team is not divided into testing team or documentation or coding team. Scrum does not prescribe a reporting hierarchy such as team lead, lead developer or junior developer.
• Optimal development team size is between 3 and 9 members. If the scrum master and the PO also perform the duties of development team member, they are included in this count. This count is just a guideline but not following it would have serious repercussions. A team size less than 3 people will likely struggle to be self-organized and cross-functional due to skills deficiency. Team larger than 9 will have serious communication and coordination problems. 

When Amazon was just a startup, Jeff Bezos defined an optimal team size as the one that you can feed with two pizzas. I think two pizza rule is applicable for scrum and is very practical advice.

Scrum Master:

• Scrum master is someone with mastery of agile and scrum concepts. He can be described in few ways such as Agile coach, problem-solver or facilitator and Servant leader.
• A servant leader does not demand team mates to be more efficient but instead helps team mates to become more efficient. He lets the team members to execute their plan.No micro management here.
• Coach and convince the development team to not skip the daily scrum.
• Often play critical role in conflict resolution. Rather than being a judge, scrum master treat each conflict on case by case basis, This means a scrum master could let her team resolve conflict on their own or could get directly involved to de-escalate the situation before it becomes a bigger problem. Scrum master intervenes based on specific context of the situation.

Scrum Artifacts

Product Backlog

• It is the to-do list for the scrum team.
• One of the three artifacts that are required for the scrum. Think of artifacts as deliverables.
• It is owned by product owner but it can be updated by anyone.
• It is the single source of truth for all requirements, defects and enhancements.
• It may also include an early rough idea that may get flushed out and implemented later
• Items in Product backlog are prioritized by product owner. Items closer to the top are fine grained, detailed and implementable and items closer to the bottom are more coarse-grained and less implementable. This is why product backlog is often compared with Iceberg with smaller pieces of ice at the top and larger pieces at the bottom.

Characteristics

• It is a living document and never complete. It continues to evolve.
• Exists as long as the product exists.
• One Product has one Product backlog and one Product owner.
• Product backlog contains multiple types of items user stories, requirements, enhancements, bugs and ideas etc
• It may also contains some items that can never be implemented. Product owner should work with other stakeholders to keep backlog clean.

Spring Backlog

• Scrum is an iterative process and scrum teams work with short and timeboxed iterations that are known as Sprints. 
• For each sprint, the development team works with PO to pull items for implementation in the current Sprint. 
• The subset of product backlog items combined with development's team plan and how to implement these items is called Sprint backlog for that Sprint.

Product Increment

• Product increment is the working product the scrum team produces at the end of each Sprint. All the business value added in the current Sprint combined with the business value added in all the prior sprints is available for the release and that is called Increment.
• Increment is the functional software that meets the Definition of Done (DoD). DoD is typically applied to all Product backlog item that is considered as done but it can also be applied at increment or release level.
• The PO may or may not release the increment to production immediately. But increment is the working software that is good enough to be released to the user community.

Definition of Done (DoD)

• When a backlog item is moved to the Done column in the agile board, that item is considered to be potentially releasable. 
• DoD can be applied to a Product backlog item, an increment or release.
• Defines criteria that must be met when the artifact is considered done.
• DoD is typically defined by an organization and is applicable to the entire organization. If DoD is not defined at organization level, it should be defined by team. Different teams can have different DoD but the definitions should not contradict each other. In other words their combined output should be potentially releasable.
• A general term for DoD is to not make too lengthy and keep it simple in the beginning. As time progresses and the processes become more mature organisation should continue to refine the DoD and should make it more stringent.
• A clear DoD enhances transparency. a key pillar of Scrum. This is because the definition makes all stakeholders aware of the progress made in building their product in a consistent manner.

Scrum Events

Sprint and Sprint planning

Scrum teams build products in an iterative and incremental manner. Each timeboxed iteration of work is called Sprint. The Sprint is often described as container event for all other events. 

Each Sprint start with an event called Sprint planning. Scrum team members continue to sync their work on daily basis in another daily event called the daily Scrum. Each Sprint ends with two events - Sprint Review and Sprint Retrospective.This entire iteration cycle is called the Sprint. This cycle continues to repeat as the scrum team build the product.

• In scrum, each Sprint has a duration of 30 calendar days or less.
• Most teams prefer sprints that are 1 - 2 weeks long.
• Each Sprint must end with potentially releasable product increment
• The Product increment may get released to the user community in production immediately or later  at the product owner discretion.
• The Product increment needs to be a vertically sliced version of the product that provides end to end functionality. It should be usable in production and provide business value. 

A good example of a product increment is working software that allows a user to search for a product by product name and price range. This includes components that works at user interface layer, business layer and also the database schema layer to support the business functionality.

A bad example of product increment is database schema or mocked user interface with no business functionality.  

Sprint best practices

Sprint zero and Hardening Sprint

Occasionally a scrum team execute Sprint at early stages of project that just focuses on planning and does not produce a working product increment. Experts would not recommended it as best practice. A scrum cycle can start with just a product vision and a team. While there is nothing wrong with having a large planning component in early sprints, each sprint should combine planning of pieces of functionality that deliver business value. The purpose of scrum is to maximize business value for each product iteration.

Hardening Sprints are designated for stabilizing products by fixing quality and performance issues. The problem with this approach is it encourages team to produce unstable product at the end of sprints and do not provide expected business values and reduce transparency of a teams progress status. For example it may look like team is progressing more than it actually has because the product increment is released with known issues that will have to be fixed in future sprint and fixing issues may take  more time than that was originally planned and there by further delaying business value to the customers.

Sprint zero and hardening Sprints should be avoided.

Spikes are research activities that are sometimes performed by scrum teams. For example, evaluating set of products for finding best solution for a specific business need. Spikes are allowed in scrum but the golden rule is to combine spike activities with other development activities so that each sprint produces some business value. You should avoid Sprint comprised entirely of spikes.

Sprint planning

Each Sprint begins with an event called Sprint planning. This event is timeboxed to 8 hours for 30 day sprint. The timebox can reduce proportionally for shorter sprints. 

Sprint planning is broken into two parts. In the first part, the scrum team defines what they are going to build in the Sprint and what is known as Sprint goal. In the second part the team will define how they will build the product increment. The entire scrum team is required to attend this event.

Daily Scrum

• Daily scrum is an event of the development team, for the development team and by the development team. 
• Timeboxed to 15 minutes regardless of sprint length
• The only required participants for this event are the development team members. The product owner is not required to attend although they occasionally participate, facilitate and provide clarifications.
• It is an inspect and adapt meeting for the development team to review their plan and progress towards the sprint goal.

Sprint Review

At the end of Sprint, Sprint Review event will take place. 

It is a collaborative informal event where a scrum team and the external stakeholders collaborate to do two things. They talk about where they stand in terms of progress towards building their product. And the second one is they discuss and decide what to do next. This is an informal event and not a scripted product demo.

This is the event where the scrum team and external stakeholders inspect the product increment and adapt the product backlog. They need to do this because they are more knowledgeable about market conditions, team performance, organizational goals, competitor roadmap and other applicable factors.

The Sprint Review is timeboxed to 4 hours for 30 day Sprint. For the shorter sprints the timebox should be adjusted proportionally.

This is the only one scrum event where people from outside scrum team, that is external stakeholders are required attendees.

The key thing to learn here is that Sprint review is not a scripted product demo. It does include an informal product demo but that review also involves stakeholders directly interacting with the product. This is followed by a conversation on what to do next. The team decides to add few product backlog items for a future discussion and de-prioritses few items. 

Daily Retrospective

Every Sprint ends with an event called Sprint Retrospective. This is the event o inspect and adapt everything other than Product increment and the backlog. In other words this is an event to discuss and create action items to become more efficient. All scrum team members are required to attend this event.

Scrum team discusses 3 things.

• what went well
• what could be done differently
• what do we commit to change

It is timeboxed to 3 hours for a 30 day Sprint and usually shorter for shorter sprint. This is the event to discuss possible improvements and issues related to processes, tools, communication mechanism, team dynamics etc.

The team selects small subset of action items and they are added to product backlog and assigned to team members. Many teams start skipping Sprint retrospective because they think their process works fine. It is always recommended to have Sprint Retrospectives for two reasons. One, you will be surprised to identify areas of improvement even when you thought everything worked fine. There is always scope for improvement. Also sometimes the things that you did well maybe the same things other teams are struggling with. If you document these items those teams would get visibility to these items and they could get your help.This is beneficial to your organization as a whole.

Product Backlog Refinement

Product owner and the development team are required attendees for backlog refinement. Unlike other events, the scrum team can conduct this event in one session or spread it across several sessions in multiple days. The guideline is the time spent on this should not exceed 10 percent of development team's capacity per sprint. For example for a two weeks or 80hrs Sprint, the development team should not spend more than 8 hours. 

The purpose of this event is to keep product backlog items detailed and ready for future sprints.

This event is used for following activities.

- Adding more details to backlog items

- Revisiting backlog item priorities

- Adding or removing backlog items to keep backlog in a cleaner state 

- Dividing backlog items into smaller and more detailed items and estimating backlog items.

The better the PO and development team execute this event, the easier it is for them to conduct Sprint planning and Sprint execution.