Author: admin

Product Backlog Refinement

Learning Objectives:

After reading through this write up you will be able to understand

• • The importance of Product Backlog refinement for development team working in sprints.
  • Role of different stakeholders and their participation in making the backlog refinement more meaningful.
  • Few important logistics for conducting effective backlog refinement session.

• Typical activities that take place during the backlog refinement.

Product Backlog Refinement

Product Backlog refinement, also popularly known as Backlog grooming, is an informal Scrum team ceremony that happens every sprint, in which everyone in the team, including Scrum Master and Product Owner get together to ensure that work items in the backlog are relevant and useful, and each items aligns to the overall product roadmap. It is indeed more of a working session than a typical closed door meeting.

Why backlog refinement?

• It largely discovers the unknowns and uncertainties that are going to share up in future during the product development. It also helps in understanding the bigger risks of the future product development.
• Regular and continuous Backlog refinement prevents “Scope Creep”, which means working on delivering something more that may not be valuable to the customer or something which results in significant budget overruns. In the absence of backlog refinement, the backlog may become partially or fully outdated, that may not suit the changing business needs.
• If you see there are lots of gaps in requirements, you probably may have to assign an action item on your PO, to come back.
• For any big technology issues or architectural issues or bigger unknowns, the team needs to work with a System architect to figure out the next steps.
• Always make sure that someone who is assigned with an action item reports back before the next planning meeting.
• If a change in the acceptance criteria of a work item has been changed, then the team should probably look at re-estimating it.
• The Scrum master should ensure that risk identification should not be dominated by single person let everyone speak up.
• Since, every team member are supposed to present in this meeting, in a way, it increases the team collaboration through knowledge sharing and learning. It also helps team to maintain sustainable pace.
• It also decreases the time for the next sprint planning meeting. A backlog refinement meeting is also called the sprint pre-planning meeting. PO will always have a good indication on which work to prioritize for the next sprint planning meeting based on the size and complexity of the work item.

 

Logistics of Backlog refinement:

• Teams typically have a standard cadence for grooming the backlog. They often have one meeting per sprint. In a 2 week sprint, it commonly alternates with Sprint Planning meeting.
• Do not schedule backlog refinement either in the early first part or the late last part of the sprint. Usually during the early first part of the sprint, the team members will try to settle down and start the work and there is every chance that the team could get distracted. If you schedule it during the late last part of the sprint, the team members will be in hurry to wrap their sprint goal and there is chance it could jeopardize the same.
• The recommended practice is could be the same day, every other week. It is the only time work not in the sprint is discussed. Usually it is a good idea to allocate 5%-10% of the sprint time for this event.
• It is recommended that atleast 2 sprints of work items are available readily groomed in the backlog, so that the team might want to pull them, whenever needed.
• This ceremony typically follows the concept of “Progressive Elaboration” which means that as we progress more into our product development, more details on the scope of work will be uncovered.
• Remember that it’s not required that all product backlog items need not be perfectly understood at the beginning of a sprint.
• The features only need to be sufficiently understood by the development team so that they have a reasonably strong chance of completing it during the sprint.
• A team can have more than one backlog refinement every sprint; it all depends on state of the backlog.
• Please rise backlog grooming issues (if any) in the next retrospective and make sure that the team suggests necessary improvements, by following inspect and adapt.
• Make it fun, entertaining and engaging, so that everyone loves attending the backlog refinement session.
• In order to derive maximum value from the backlog refinement meeting, it is recommended that backlog grooming meetings are Time boxed, with strict agenda, a specific goal in place and PO come prepared.
• It may be Okay for managers and other stakeholders to attend this session, but Scrum Master has to work towards limiting their participation only to listening and jump in when they are asked relevant questions on the backlog items being discussed.
• Mike Cohn, the founder of Mountain Goat Software, proposed acronym DEEP to summarize key attributes of a good product backlog

Detailed Appropriately	Highest priority, more detail; lower priority, less. Broken down into smaller stories for sprints/release
Emergent	Growing and evolving overtime;  Re-prioritized when items are added/deleted
Estimated	The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.
Prioritized	Items that are slated for the next couple of sprints

 

Product Owner involvement:

• The product owner involvement is vital in backlog refinement.
• It is always recommended that PO should spend atleast 30% of his available time with the development team during a sprint.
• The PO makes important decisions about acceptance criteria, acceptance tests, logic details, and priority of the work items during the backlog grooming meeting.
• Ideally a grooming meeting has most verbal conversations that engage PO and development team. The Scrum Master facilitates this ceremony

 

Typical activities during the backlog refinement are

• Reviewing the highest priority stories on the top of the backlog
• Ask questions to product owner for more information.
• Deleting stories that are no longer needed
• Writing new user stories
• Re-prioritizing and force ranking the stories
• Re-define the acceptance criteria
• Creating new user stories when necessary
• Estimating or re-estimating stories
• Re-assessing the relative priority of stories
• Breaking the epics further into user stories
• Refining stories to prep for future sprints
• Understand the changing bigger picture of the product architecture as the backlog emerges.

 

Scrum Smells if

• There are no backlog refinement sessions
• The entire team not present, only leads try to understand more than others
• The stories need to be groomed / estimated during sprint planning meetings
• There is lack of sufficient acceptance criteria for user stories.
• The time spent grooming stories is not proportional to its position in the backlog

 

How Testing and Agile work together?

 

Unlike traditional waterfall models, where testing was treated as a separate phase by itself with silos teams and heavy weight processes built in, agile principles strongly prescribe that testing as a practice that will evolve and involve all development team members of a cross-functional team. Testers in the team bring in special testing expertise to the team, with constant interaction with other team members to ensure delivering the early business value desired to the customer at frequent intervals maintaining a sustainable pace. Since Agile roles largely overlap, early and continuous testing is the key to maintain high quality.

Agile software development emphasize that testing is an integral part of the software development and it recommends using the “entire-team” approach to embed quality into the software product development. Both coding and testing are done iteratively and incrementally to build the business value upwards, until it get full points from the customer. So feedback and collaboration between the developers and testers is the key to make Agile testing successful.

Agile principles replace the need of a dedicated Test Manager with short feedback loops of interactions between the Product owners and team members. Agile testing also influences developers to contribute to testing, since all agile team members are generalized specialists. So Agile testing is a team effort and not the QA testers alone. Testers also help developers in the team, to design and write unit test cases. Other team members may give the feedback using “Show and Tell” technique before the code being checked in into the repository. In short, developers are encouraged to think more like testers, continually checking their own code for potential errors, and testers are encouraged to think more like developers, tempering their natural destructive tendencies to engage more fully in the creative process itself.

Definition of Done is called the exit criteria, before we call a story/sprint done gives a checklist, not to ship anything without the criteria not being met. The acceptance criteria of user stories may be refined to relate the user stories to a testable outcome.

Extreme Programming (XP) gives set of best engineering practices to introduce quality in Agile development.  Test Driven development (TDD) is a test first model. Start development with a unit test case, make it fail, then make it pass, and refractor it gradually. We call these three stages as Red, yellow and green. We can also expand TDD to acceptance testing as well.

Pair programming is another practice, in which a tester can pair up with another developer to test and give feedback on a piece of code.

Agile testing strongly recommends test Automation at every level. Writing automated acceptance test cases that will test business logic using API, hooks, business logic layer and GUI is called Acceptance Test Driven Development. These tests should be implemented as a part of the continuous integration platform. Automating all the test cases gives us an edge to perform quick regression testing at the end of every sprint to make sure that something was developed before was not broken. It is also advisable to check in the automated tests into the repository for future references and modification.

Exploratory testing is another face of Agile testing which involves testing at a broader level uncovering the implicit expectations, without any test documents. It bring outs the critical and innovative thinking, and diverse ideas to make the better software products.

Various tools used for agile testing:

JUnit, Native Groovy, JMETER, SONAR, Selenium, DBUnit, Cucumber, Crucible, Jenkins CI, Hudson CI

Top 10 things to think about when offshoring your agile development

 

1. Choose a partner who delivers early and frequent Business value over fat invoices
   One of the hardest parts of Agile Offshoring is choosing the right partner. Finding the right partner pays back in long term. A partner must have the right mindset to understand the meaning of business value. Partners who love to collaborate on daily basis to understand the end customer’s priority and capable of absorbing fast changing business conditions and translate the same into working software may be best suited. Avoid getting into T&M and fixed bid contracts as they never get you into a win-win situation. . In case you don’t find a partner whom you are looking for, get into outcome based contacts, where the dollars billed are proportional to the outcome delivered.

 

2. Do not undermine country specific culture
   Cultural change may make or break new products. Indeed, this could be a major reason why several organizations have problems adopting agile methods. Many companies operate with a command and control model which assumes that seniors make all the decisions and people below execute them. To make agile methods work, there needs to be much more autonomy, freedom and decision making given to the teams which do the actual work. This problem is even worse when you choose a partner based out of Asia. There are few environments where people are often discouraged from asking questions, talking about problems openly, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. This really takes long time to address problems, since they are not raised when are spotted. So in true sense making teams truly self-organizing is still a night mare in some Asian cultures. The middle managers who are enough threatened of losing their jobs by agile adoption, often play the spoil sport. Bringing and anti-authority attitude may still take time in Asian cultures to get the best out of teams.

 

3. Strictly, no big bangs
   Big bangs always lead to explosions, so it is advisable to start small and progress gradually towards scaling to next levels. Changing multiple set of variables simultaneously, without doing proper due diligence could invite quick disaster. It may inevitably leads to more stress, confusion, frustration and finger pointing. Do not dump everything at once on offshore, unless you are sure that it working for you. Take time to assess and understand each team and their continuous performance improvement, to make meaningful decisions.

 

4. Use highly fidelity communication equipment
   Agile distributed teams, who are non-collocated, may not always get sufficient time to talk to each other.  Continuous flow of Communication across the locations is the most important parameter for the success of the agile teams. Miscommunication between the locations can lead to building the wrong functionality which may jeopardize the customer satisfaction. Invest in engaging teams in several small and frequent powerful conversations, across the locations. A high fidelity in house video conferencing is a best way to replace face-to-face communication. Other options that can be looked upon are tools that facilitate instant messaging, Webex sessions, screen sharing, desktop/laptop video conferencing tools like Skype, Google Hangouts. It is preferred to get multiple modes of communications were established and working early before offshoring begins. Try minimizing the document driven approach with the offshore teams.

 

 

5. PO availability is vital
   Product Owner’s availability to offshore teams plays vital role for teams to understand what they to work on.  It is recommended that the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the release planning, the review, and the retrospective meetings. There are several recurring issues with distant product owners, including mistrust, miscommunication, misalignment, slow progress and lot of email communication.

 

6. Promote ONE Team behavior
   In most of the distributed teams, the teams located in either geography often behave as different teams. There is often lack of trust and miscommunication surface between them. They also tend to throw at each other to cover up mistakes.  Offshore team members must gain the trust and understanding to make their own decisions, instead of waiting for the onsite team. Promoting ONE team behavior is a great challenge for the management.

`     Few techniques that are worth experimenting are

• Create Proxies for PO and ScrumMaster to avoid communication gap. A proxy is a person acting as a placeholder for the actual person behind the screens, who shows up when needed.
• Establish working agreements with the WHOLE team.
• Create Definition of Done and Definition of ready with the WHOLE team
• Have all scrum ceremonies with WHOLE team.
• Communicate the customer feedback with ENTIRE team.
• Make one product backlog for ENTIRE team.
• Try to mitigate the time zone differences through negotiations
• Do not create development and testing teams separately at onsite and offshore, instead encourage everyone do a bit of both.

 

7. Encourage using best engineering practices
   The extreme programming (in shot XP) suggests the use of best engineering practices across the global locations for teams to increase productivity.

Few examples of best engineering practices are:

• Pair programming strengthens the behavior of collective code (shared code) ownership across the team. It also mitigates the risk of attrition or key personnel loss in the team.
• Encouraging test-driven development, acceptance test-driven development increases the code quality and protects the team and product from scope creep/gold plating.
• Continuous integration enables the smooth flow of software development across the geographic locations. The customer may also try his hands on the latest work developed and correct any misunderstandings of the requirements.
• Continuous refactoring and deployment reduces the technical debt and increases the customer satisfaction.
• Code reviews, Test Automation and exploratory testing increases test coverage and code quality.

 

8. Enable continuous feedback loop with the end customer
   Often requirements are seen as bullet points which the developers have to implement. The importance of feedback loop is often forgotten, since the offshore teams are not connected with the end customers. On an agile project, if customer and development team work together more frequently, it will help each other to spot the difference of understanding instantly. Moreover, due to less rework, it is easy and cost effective to change a system that was partially developed. It is advisable that remote/offshore teams demo the software to the end customer to increase collaboration between developers and customers.

 

9. Invest in short visits
   Investing in short and frequent visits for events like release planning play an important role to increase good personal relationships among the teams. These visits which can be of minimum 2-4 weeks also help teams to maintain the relationships and trust which need to be in place for remote communication to work effectively. The problems which may cause a lasting damage to the project can be repaired easily with the human touch involved during these short visits. Dinners and sightseeing can often be the most useful activity that the visitors do with the hosts.

 

10. Use common tools and repositories
    There are several tools available in market place that increases collaboration between onsite and offshore teams.  Creating a robust repository for both teams to share their source code like SVN is a good way to start. Both teams can also record all their specifications, test cases and other design artifacts. Both teams may also share a combined task wall during their daily standup.  Commercial tools like Rally, Versionone may be used for creating product backlogs, sprint backlogs, burn-downs on a daily basis. Several free tools for defect tracking like Bugzilla may be evaluated. Unit testing tools like Junit, cyclomatic code complexity tool like SONAR are few good options for teams.

Wiki could be good option for circulating common information, Wikis work well because they are simple to use, can be worked with any browser, and are simple to set up.

 

What are acceptance criteria?

Acceptance criteria are statements of requirements that are described from the point of view of the user to determine when a story is “done” and working as expected. It would bring in lot of certainty to what team is already building. Acceptance criteria are emerging and evolving and assumed to be flexible enough to change until the team starts working on it.

Example Story:

As a customer, I would like to have an email sent to my normal email address when my account goes into overdraft so that I know that I need to put money into my account.

Acceptance Criteria:

When and account goes into overdraft, the system will issue a secure message to the user’s account, then the system will:

1. 1. Check to determine if the user has a valid email account in their file
      1. 1. If there is a valid email address on file, the system will send a message to that address indicating that a message is available
         2. If there is not an email address on file, the system will flag the account as incomplete
   2. The message sent to the customer’s email address will match the text provided by marketing
   3. The email sent by the system will be formatted for HTML viewing and will match the graphic design specifications sent by marketing
   4. The email will contain a hyperlink which allows the user to jump instantly to the online banking site

 

In the above example, Acceptance criteria are merely set of statements that represent the requirements “conditions of satisfaction.  It also contains boundaries and parameters that determine when a story is completed and ready for acceptance. It expressed clearly in simple customer language without any ambiguity on what is expected as outcome. It must be easily actionable and translated into one or more manual/automated test cases. When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied.

The format of an acceptance criteria can be understood as:  “When I enter X & Y, I will check for Z as the result “. It should always relate to testable outcome. The focus must be on inputs, outcomes and business flow.  Anyone in the team like business analyst, QA and developers can help the PO in reviewing the acceptance criteria.

The 3C’s

Nearly around 10 years ago, Ron Jeffries mentioned the Three C’s of the user story

• Card – stories are traditionally written on story cards, and these cards can be appended with extra details as required
• Conversation – additional information which are not part of the acceptance criteria are conversed between the team and PO, the team tries to understand the PO intensions behind creating a user story.
• Confirmation – acceptance tests confirm the story is finished and working as intended.

 

Advantages of Acceptance Criteria:

• It will trigger the thought process for the team to think through how a feature will work from end user perspective
• It also helps the team to write the accurate test cases without any ambiguity to understand its business value.
• Eliminate unnecessary scope that will add no value to the story, in other words, it will keep the right content.
• Wireframes can be attached to acceptance criteria, so that the team can discuss during the planning meeting.

Making Wireframes

The primary purpose of wireframe is that it will easily depict the screens designs and layout plan according to which the end user processes the information. It may be also treated as mockup blueprint of two-dimensional black and white diagram for developers to understand the intent, before they build the actual product. For example, wireframes can contain various states of button on a screen or menu behaviors or drop downs that make an impact to the screen that is being designed. Wireframes are created to accomplish a particular purpose of dealing with various interface elements, navigational systems and the website content.

Wireframes may also be hand sketched on a white board without using complex commercial software applications and tools. However, there are some commercial tools available in the market exclusively for making wireframes. Wireframes are generally are created by Product Owners or business analysts, user experience designers or developers that have overlap with information architecture and user research.

Wireframes focus on:

• The relative priorities of the user elements and information available on the screen.
• The end to end functions available on the screens.
• The versatility of the information displayed
• The business rules that relates to the UI elements.
• The effect of different scenarios on the display.

Some of the wireframe tools that are available in the market are:

• Mockingbird
• Lovely Charts
• Gliffy
• Mockflow
• Pencil Project
• SimpleDiagrams