Friday, October 20, 2017

The Product Backlog Refinement Meeting in Scrum | Supreme Agile

Like a flower growing wild when unattended for too long, the product backlog becomes complicated and non-manageable when it's neglected by the product owner and the team. To overcome this problem and keep the product backlog in a healthy shape, the product backlog needs to be treated with care and attention during each day of the project.

The process that we will use to achieve this goal is called "Refinement", in this process the product owner and the scrum team review the backlog stories and validate that those stories are relevant, Contains the relevant information, prioritized and that the top stories are ready for delivery.

תוצאת תמונה עבור ‪Refinement meeting‬‏

Is it an official scrum meeting?

Although the Refinement meeting has a lot of benefits that will contribute to the process it is not an official scrum meeting (In my personal opinion it MUST be added to it). As more and more teams are using scrum, we can see that more and more of them are discovered this meeting as valuable for both the overall process and the scrum team.  

Grooming or Refinement?

In the last few years we can see more and more companies that use the word "Refinement" instead of "Grooming", the main reason for this syntax changes are most probably related to the negative connection of the word "Grooming", so just know that this process is the same but in some environments, it may also be called "Backlog Refinement".

The Refinement processes

During a product backlog Refinement meeting, both the team and the product owner review the TOP backlog user stories, during this review, each team member has the chance to ask any question that will help him to gain more information about the story and as a result to reduce the same question (Technical and Theoretical) that will most probably be asked during the planning meeting.

Once the questions are asked earlier, the product owner can provide answers immediately, but in some cases the answers are not provided during the meeting, the main issue here and probably the main key of success, is that the PO will address those questions in a way that will help the team to gain confidence in those stories prior they will perform their commitments.  

How Much Time does Refinement Require?

To answer this question, we need to use two main parameters, the first one is the maturity of the product, if the team is familiar with the product the amount of uncertainty and risks are reduced accordingly, the second parameter is the maturity of the product backlog, at the start of the project you will most likely need to invest more time in Refinement sessions that will be reduced once as long as you proceed with the project.

The time basic assumption is that you should assign 5-10% of the team hours for backlog Refinement that should take 2-8H per sprint (The time will be changes based on the two factors described above).

The Refinement Activities
The Refinement process includes different activities that the team will have to follow to make the process right:
  • Splitting large user stories which the team cannot accomplish during a single iteration.
  • Estimate stories and update old estimations based on new information.
  • Splitting user stories that are just too complex for the team to handle.
  • Remove user stories that are not relevant to the project.
  • Add new technical user stories based on the team needs.  
  • Add new user stories based on customer requirements.
  • Remove irrelevant dependencies between stories.
  • Update stories that are not relevant anymore.
  • Stories are reviewed and updated with DOD's, Acceptance criteria and information that will help the team finish the stories.
  • The product backlog is prioritized, the top priority stories will be shown at the top of the list.

How can you Maximize the value?

It’s not a rocket science, the same rules and guidelines that are relevant to any other meeting are also relevant here:
  • Make sure that the backlog stories are updated based on the participants' comments.
  • Let everyone to ask their questions and make sure you provide the answers.
  • Come with a predefined GOAL, the product owner should start the session with a short description about what he wants to accomplish and set the meeting goals.
  • All participants should be motivated to participate and contribute.
  • The meeting should be held without any external interruptions.
  • The meeting should be kept under an agreed timeframe.
  • Only the relevant stakeholders should attend.
  • At the end of the meeting the product owner should validate that the team is familiar with the goals of the next sprint.
  • Invest in the TOP user stories, do not waste time in user stories that may become irrelevant in future sprints.

What are the expected benefits?

  • The product backlog is kept prioritized and ready for the next planning meeting.
  • The Refinement process will help to increase the clarity of the user stories.
  • The Refinement process is fun and will elaborate the team collaboration.
  • The Refinement process will increase the dialogue among the team members and between the team and all other stakeholders.  
  • The Refinement process will help to ensure that the user stories are updated with the relevant details, DOD's and time estimated.
  • The Refinement process will help to reduce the time consumed during the sprint "Planning" meeting because the team is already familiar with the user stories that they will need to commit throughout the sprint.
  • The product owner and the than engage in face-to-face conversation rather than communication via backlog.
  • The Refinement process will help to create a collaborative ownership among the team members.

Saturday, October 7, 2017

Job Interview Mistakes to Avoid | David Tzemach


In this article, I will review the main mistakes that you can do during an interview in the software industry, the list is combined with my personal experience and from stories that I gathered along my 12 years in the software industry.

The principles

Prior to reviewing the list, let's talk about the key principles that you must be familiar with.
·         The software industry has many opportunities that you can use to find your next job.
·         My list will help you to avoid the basic mistakes that are interview "Killers".
·         Try to find the hidden goals behind the interviewer questions.
·         The software industry needs more and more people.
·         Remember that when you go to an interview, you should always position yourself as the solution to their problem.

Interview killer mistakes


1.       Make sure that your resume is reflecting your real knowledge.
2.       Your CV is not focused on the specific job that you want.
3.       Never lie, a good interviewer will catch you!
4.       Providing the wrong contact information.
5.       Validate that your resume is short.
6.       Make sure that your CV contains the relevant data, the interviewer does not care what you did 100 years ago.
7.       Never have a Grammar error.
8.       Never have a spelling error.

Interview preparation

9.       You don’t know what is the exact position that you invited for.
10.   Failing to understand the importance of a phone interview.
11.   Failure to explain why you are the best man for the job.
12.   You don’t know what characteristics of the job.
13.   You don’t know the requirements of the job.
14.   Remember what you wrote on your resume.
15.   You don’t know what the company does.
16.   You use assumptions instead of facts.
17.   Do not answer with 'Yes' or 'No'.
18.   Keep the basic Dressing codes.
19.   Know the salary expectations.  
20.   Do not late to the interview.
21.   You failed to ask questions.
22.   Do not arrive too early.

Personality Mistakes

23.   You are nor demonstrating enthusiasm.
24.   Showing off, no one will appreciate it.
25.   Sounding too desperate for the job.
26.   Speaking rudely to the interviewer.
27.   Not receiving any criticism.
28.   Forgetting your manners.
29.   Do not be too emotional.
30.   You are being too needy.
31.   You Become Defensive.
32.   You Become angry.

Interview mistakes

33.   Don’t ask about the job benefits of the first phase of the interview.
34.   You indicate that you are not willing to work after official hours.
35.   You indicate that you are not willing to start at the bottom.
36.   You indicate that you are not willing to work in a team.
37.   You are using a "Slang" language during the interview.
38.   Failing to listen to what the interviewer is telling you.
39.   lying about your experience and knowledge.
40.   Making an obvious weakness seem positive.
41.   Bad-mounting your former employer.
42.   Don’t lie about your salary demands.
43.   You failed to explain your strengths.
44.   Negativism against the interviewer.
45.   Trash talking with the interviewer.
46.   Complaining about stupid things.
47.   Do not ask too many questions.
48.   Failing to make an Eye contact.
49.   Interrupting the interviewer.
50.   Leaving your cell phone on.
51.   You apologize too much.
52.   Overselling Yourself.
53.   Don’t talk too much, philosophy is great, but you can keep it to yourself if you didn't ask to explain it.
54.   Chewing gum.

Tuesday, October 3, 2017

The Scrum Product Backlog | Supreme Agile

In traditional project management, the development team realize on a fully detailed SRS that determine the entire product specification prior to starting their work, in Agile, the product backlog is used to replace these requirements.  

תוצאת תמונה עבור ‪scrum board‬‏

The product backlog is a prioritized list of user stories, these stories are used to determine the work needed to be done by the team in order to deliver incremental releases of the product. In Agile, the product backlog does not contain the entire specifications needed to accomplish during the project (Why do we need to waste time in creating documentation that most likely will be changed in the future?), instead, the product backlog is used as a "Living Document" that changed based on the authority of the "Product Owner" during the project. 

Items in the Product Backlog

The product backlog contains a few mandatory items that we will use in order to determine the project effort and to increase visibility, A typical Scrum backlog will contain the following types of items:
  1. Epics, Features, User stories and Tasks.
  2. Functional Requirements.
  3. Non-Functional Requirements.
  4. List of Defects.

Each item may include the following attributes:
  • Work Estimations (Determined during the planning meeting)
  • The amount of value it’s add to the project.
  • Description about the work needed to be done.
  • Acceptance and Definition of Done(DoD) criteria.
  • Priority Level (Order). 

The Hierarchy of the Product Backlog

There is a simple Hierarchy that we want to see in a product backlog (Especially if it's the first time you need to create it):

Epics -> User Stories->Tasks
I will create a specific article about Epics, but for now let's use them as an "High-Level" user stories, these large stories are sometime created without the full knowledge of what they will become (remember that we will not write the full requirements of the project) in the future.

Each epic may contain a large amount of user stories that are used to achieve a larger goal driving from the targets we determine in the Epic story, during the project the team will refine the backlog to make it more precise and accurate for the team.

During the planning meetings, the user stories are divided into smaller containers of work called "Tasks", these tasks will determine all effort needed to be accomplish by the team in order to finish a user story (PBI), Examples:
  1. Need to make a research about the technology we will use.
  2. Need to design and created Automated tests.
  3. Need to define the architecture and Design of the new component.
  4. Need to integrate the new code into CI. 

My Presentations