Agile- Understanding Scrum Part 4(Scrum Artifacts)

In this post i am going to talk about different artifacts involved in scrum. We will talk about what these artifacts are and how these are utilized practicing scrum.

Product backlog –
1) What is it – It is list of features containing short description for all functionality desired in the product. It need not to be end to end long description, instead it can be short description sufficient to create a development task. The more detailed information will evolve sprint by sprint based on user feedback.
2) Content – it contains Features, Bugs, technical work(example- environment setup) and knowledge acquisition(example – evaluate a library for use).  In general the features are listed as user story, which is written from user perspective. It is more of language like “As a user I want to ….”, with this format its easier to understand the end goal of the story.  There is not difference in feature or bug, when it’s written in user story format.
Rules - It should be visible to all who cares to see it(value transparency) .  Work at the top of the product backlog should be sized and understood by the development team and product owner both. If the product backlog is not ready, then sprint planning is cancelled.

Sprint Backlog –
1) What is it – during sprint planning meeting, scrum team picks up top priority item from product backlog and moves it to sprint backlog. 1 item from product backlog can have 1 or many corresponding items in sprint backlog.
2) Content – Sprint backlog is list of tasks identified by scrum master to be completed during sprint. While picking up these items it’s important to estimate the effort as well, so that you have clear idea on how many items can be addresses in given sprint.

Burndown chart –
1) What is it – Each day, estimated work examining in the sprint is calculated and graphed by scrum master, resulting in sprint burndown chart.
2) Content – Burndown chart shows more of the progress over time for the team. Horizontal sprint show sprint and vertical axis shows amount of work remaining.  Work remaining can be in any unit like story points, days or anything else. The burndown chart also helps understanding the estimation accuracy. If the progress line is coming above ideal work line, which means your work is completing slower than expected, hence you underestimated the timeline. And if you overestimate the time required, the progress will appear ahead of schedule, means below the ideal work line.

Agile - Understanding Scrum part -3 (Scrum Ceremonies)

Today we are going to talk about Scrum Ceremonies. These are set of meetings. We will learn about who is primary audience, what is the agenda of these meetings, and how short or long these meetings should be.

Planning meeting -
1) Attendees – It has to be attended by entire team including product owner, scrum master and the scrum team. Stakeholders and users are optional attendees.
2) Agenda – Product owner will describe the high priority features to the team. The team can ask as many questions as they want to understand the user story, so that they can translate into dev tasks and can create sprint out of it.
3) Duration - it should be time boxed to at 2 hours per week of sprint.
4) Prerequisite - Before this meeting, product owner has to have ordered product backlog, out of which scrum team can create their sprint backlog.
5) Outcome - At the end of the meeting, sprint backlog and spring goal has to be finalized. Also the it should clearly define the forecast of work in the sprint.

Daily Scrum meeting –
Objective – Objective of this meeting is to understand what  everyone in the team is doing.  Team has to answer only 3 questions what did they do yesterday, what’s their plan for today and are there any blockers for them.
Attendees – scrum team. Scrum master can facilitate this meeting, but this meeting is mainly for developer team only.
Duration – it has to be very short meeting, around 10-15 mins. This is the reason that it should be stand up call so that everyone covers it quickly.

Sprint Review –
Objective – At the end of every sprint, there has to be coded, tested and usable software available for client. The objective of sprint review meeting is to showcase team’s accomplishment.  In general it is more of a demo of new features.  During the meeting product is assessed against the sprint goal determined during planning meeting.
Audience – This meeting is attended by all members and can be attended by product customers and management as well. The developers from other products can also attend this meeting.

Sprint Retrospective –
Objective – Main objective of meeting is to evaluate how we as team are doing and what are improvement areas.  Identify areas for - a) What should we start doing? b) what should we stop doing? C) what should we continue doing? The ideas are taken from everyone and are voted in the last to conclude the modified practices.
Attendees – Entire team, scrum master.  Scrum master will facilitate this meeting and go around the table to ask people their ideas.
Duration – This meeting can be an hour long, as this is more of self-evaluation. Sometimes it can take longer as well, because there can be some conflicts which requires more brainstorming.

Agile - Understanding Scrum part -2 (Scrum Roles)

Today i am going to start understanding the basic terms used in scrum. I will cover more detailed concepts in upcoming posts, but want to start with introducing terms used in scrum.

Product owner–
1) Key stack holder – Product owner is key stack holder of project. It could be business analyst (working closely with business and users of product) or anyone someone from Marketing or anyone with solid understanding of users and marketplace, the competition and future trends for domain. Product owner should have a clear vision on what he/she wishes to build and convey that vision very clearly to the scrum team. Product owner is key to successfully starting any agile software development project.  Product owner maintains the product backlog.
2) Does not Dictate estimates – The product owner prioritizes he product backlog during sprint planning meeting, but it is development team that selects the amount of work they believe they can do in given sprint and how many sprint will be required. Product owner never tells development team how much work they should do in given sprint or how many sprints are required.  The estimation comes from development team only.
3) Changing requirements – Requirement can change within sprint, and product owner has every right to do so, but it will never impact current sprint. The change will be taken as new task in the next sprint planning meeting and will be prioritized.
4) Required Skill set and network – Product owner should have certain skills like business or domain knowledge, good communications and connection with the team. The product owner role requires working closely with the users, stockholders across organization and the development team; hence the communication is one of the most important skillset desired in product owner.

Scrum master –
1) No authority over team, but authority over process – Scrum master do not have authority over team, but has authority over process. Scrum master can tell you at end of sprint that what went right and what needs to be improved, but he/she can never dictate “how to do it”. It is all up to the team on how to do it, Scrum master will help them coming up with proper process. Moreover the team can give some more authority to scrum master, if they feel so.
2) Works as guide or trainer - Scrum master is to help team understand the process and practices of scrum. Like any exercise trainer, who will help you understand the workout, but will not do workout for you. Also, trainer will make sure you don’t skip any hard workouts and all necessary tools are with you to achieve your goals. Similarly Scrum master will help you like trainer, will help you understand process, help you remove any impediments and help you establishing a proper process around to get quality product in timely manner.
3) Do not manage people – Scrum master does not work like project manager, hence do not have direct control over people. Project manager can dictate clearly what needs to be done, but a scrum master will never give you detail on how to complete a task.

Scrum Team –
1) No roles – The scrum team does not have any roles like programmer, designer, tester etc. Everyone in the team works to complete a set of task within sprint.
2) Team size – in general scrum team is of size 5-9 people. Smaller team helps having scrum meeting shorter and discussions to be quick. We can have scrum of scrum meeting for larger team where 1 person from individual team can represent their work and coordinate with multiple other scrum teams. 

Agile - Understanding Scrum part -1(Introduction)

Introduction - 

Scrum is a framework for developing complex products and systems. It is grounded in empirical processs control theory. Scrum employs an iterative, incremental approach to optimize predictability and control risk. - Ken Schwaber

What is framework? - A framework is an incomplete structure which accommodates other practices, techniques and tools while providing an overarching process.
What is methodology - A complete set of prescribed and interrelated principles, tools and practices working together to achieve a particular goal.

Scrum is a framework. This is the reason that scrum can co-exist cleanly and even support other development methodologies and techniques. Extreme programming, KANBAN work really well using conjunction with Scrum.

Scrum is Empirical. Which means it doesn't have predefined steps, instead it works on feedback loop, continuously improvising the process. It is absolutely needed when we don't know the exact expected outcome at the time we being. This kind of feedback loop help us taking shorter steps, and improvise with feedback. It tell you fail, and fail fast, so that you can take corrective measures and move ahead.

Scrum is iterative - These are the steps followed in any product delivery - Plan -> Analysis -> Develop -> Test -> Integrate -> Validate -> Deploy. Scrum says, instead of doing these steps once , do it many times with smaller deployment and releases and reiterate it over and over again.

Scrum is for Complex work - Scrum is not meant for simple or even complicated work, it is meant for complex work. Here is the complexity illustrated by professor Ralph Stacy -

Scrum talks about Product, instead of Project - Software development should align with product, which is more usable software. instead of delivering a big project, focus should be to deliver smaller patches of product, which can be used by the consumers.

Scrum is Iterative and incremental agile software development framework for managing product development. It defines “flexible, holistic product development strategy where dev team works together as single unit to achieve common objective”.

In scrum instead of providing complete detailed description, it is left up to dev team to figure out. Scrum relies on self-organizing(no leader), cross functional team.

Overview – 

Scrum is agile process used for product development. It is project management framework to achieve aggressive deadlines and complex requirements. In scrum projects move forward by series of iterations called sprints. Sprint is generally 2-4 weeks length.

The scrum is not just about changing development approach, it is also about behavior changes. It talks about certain key values that everyone in the team should respect. These values are -
Respect - Always respect everyone in the team. Respect their decision and their point of view.
Trust - The trust is something earned over time, trust your team and build trust with them.
Commitment - Always be committed to you tasks, because if you fail, the entire team fails.
Focus - Be focus on your items.
Openness - Always share your progress, thoughts and decision with all, nothing to hide from anyone.

These value can be understood with following practices in scrum -
Because we value respect we will keep chit-chat outside of daily Scrum meeting.
Because we value trust we will only show done Features at Sprint Review.
Because we value commitment we will turn up on time.
Because we value focus we will not interrupt someone with headphones on unless absolutely necessary.
Because we value openness we will post these decisions on the wall for all to read.

One of the very important concept in Scrum is Time Boxing. Scrum clearly says that every event and activity has to be time boxed. Hence we have a concept of Sprint, which gives us a container to keep all the artifacts of Scrum together and in time boxed manner. 

Time Boxing -
Any event should have maximum duration (not minimum) in scrum. This means if a meeting is supposed to be an hour, than we have to wrap it up in an hour, no extension.  It actually provides us a container to self-organize our self and collaborate more in the meeting, which helps individual to focus more on priority items and eliminate distraction.

Sprint -
Sprint is a time boxed event of scrum. It is limited to 30 days or less. Limiting duration help us reduce the risk because we get to know the feasibility of any given task within that amount of time. Also it help helps developers to be more focused.
It is container of all other events of scrum. Product owner can cancel the sprint if he/she wants. Sprint is inviolable, which means non planned work will never be included in current sprint. If there are more high priority items come up, product owner can list it for next sprint.

Let's try to understand different items kept in sprint-
1) Roles – Product owner, scrum master, team

2) Ceremonies – sprint planning meeting, sprint review, sprint retrospective meeting, Daily Scrum meeting

3) Artifacts – product backlog, sprint backlog, burndown chart

Roles - 

Product owner – project key stackholder and represents users for whom we are building this product. Product owner has to have a deep knowledge of business requirement. 

Scrum Master – SM is responsible for making sure the team is as productive as possible. SM is responsible to building the scrum process in the team by removing impediments to progress, protecting team from outside distractions. 

Scrum team – Typical scrum team is of size 5-9. There is no team lead, designer, tester etc. instead the entire team work towards the common goal as a whole.

Ceremonies -

Sprint planning meeting – At start of each sprint a sprint planning meeting is held, during which the product owner presents top items on the product backlog to the team, the Scrum team selects what they can complete during the coming sprint. Then that selected work is moved from product backlog to sprint backlog. 

Sprint review meeting – At the end of each sprint, the team demonstrates what they accomplished during sprint in the review meeting. This is more of demo to the business owner to showcase the product at end of sprint. This should not be very long for dev team.

Sprint Retrospective -  This is the meeting where scrum master, product owner and team meets and find what’s working and what’s not. They discuss and come up with the new approaches if the process requires any improvement. 

Daily Scrum Meeting- Each day during sprint, the entire team meets (at start of day) and cover 3 areas – what I did achieve yesterday, what do I plan to achieve today and if there is anything blocking me. It is more of stand up so that the updates and discussion are not lengthy.

Artifacts - 

Product backlog – product backlog is prioritized list of features, or changes in features. 

Sprint backlog – sprint backlog is list of features/task that team wants to complete within that sprint. 

Burndown chart – The team tracks its progress against release on burn down chart. The chart is updated at end of each sprint by scrum master. 

Scrum Flow -