This is a summary of the beginner session.
D: Discussion points
Q: Scrum Values?
D: Practicing Scrum requires a discussion of three sets of values. The Agile, Scrum, and team values. Since the team values are best discussed with the team, lets focus on the first two.
Agile values from the Agile Manifesto document.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
D: That is, people interaction should be frequent instead of communicating via tools and process. Consider all the Agile and Scrum events occurring every week.
Working software over comprehensive documentation
D: Unlike our Waterfall projects, percent complete is more impactful when the discussion is not on the completed work task, but on how much of the final outcome has been completed. Focus on software and other outcomes, including any documents, being requested. As for the documents required to deliver the outcome, work to keep it short and to the point. Use pictures when possible. Another mind shift from the volumes of documentation created in past projects.
Customer collaboration over contract negotiation
D: That is, before beginning the contract negotiation conversation, first establish a client partnership, understand what they need, and see what Minimum Viable Product (MVP). Once this is understood, the contract negotiation takes on a different feel.
Responding to change over following a plan
D: That is, it is great to have a plan to follow. However, you cannot be a slave to your plan. In life things change for the better. Welcome it and make it part of the new plan. It could be the only way to get the client satisfaction being sought.
That is, while there is value in the items on the right, we value the items on the left more.
Now the five values in Scrum.
Commitment - team members need to be committed to delivering on the sprint goal and being there to help the team complete stories required to get there.
Focus - the team should only be focused on the work to deliver the sprint goal.
Openness – Honesty and transparency are key to a health team relationship. This requires sharing success, failures, “I do not know how to do this”, ideas, opinions, concerns, and anything else that is need to get to the sprint goal.
Respect- always act in a respectful manner to each team member and their contribution regardless of how small.
Courage – to do the right thing. Act in a collaborative manager while demonstrating each of the four above.
Q: Sprint Planning process?
D: We began by discussing the inputs and outputs.
Stakeholder needs captures and converted into a Product Backlog by the Scrum Team with the Product Owner (PO) taking the lead. Then the PO continues working with the team to refine the user stories to prepare them for Sprint Planning based on the Definition of Ready (DOR) policy agreed to by the Scrum Team. For example, decomposed user stories sized and ranked to deliver the highest business value and decrease risk.
Past, should it exist, completed story points for the last 3 to 5 iterations trend with emphasis on completed in the last two to avoid taking too much.
Definition of Done (DOD) policy to be used when deciding what work might be required and revision that may be discussed.
Sprint Backlog containing the sprint goal, user stories, and tasks to complete the user stories as per the DOD policy. It should/could also contain board or column WIP limit(s), entrance and exit polices.
Event Calendar so everyone is aware of the time box events, including the Sprint Review (Demo), the team must prepare.
New completed story points metric for the velocity trend.
Revised Definition of Done (DOD) policy to be used when deciding what work might be required and revision that may be discussed.
Product Owner, required
Development Team (AKA, The Team), required
Scrum Master, required
Any person / role the team may request to address an unknown or request during the time box
Definition of Ready (DoR) policy is used to determine when a user story is ready to for Sprint Planning.
What we want to do?
Last minute conversation on the upcoming sprint and any last-minute changes.
Presentation of the final user story value ranking for user story selection.
Team member availability discussion and impact on team capacity and event schedule calendar.
Team discussion on user stories to be pulled based on business value ranking, risk reduction, for the Sprint Backlog based on team velocity metric.
How we want to deliver the sprint goal?
Team discussion on how to deliver the user stories.
Discussion of task required.
Dependency or resource constraints which could impact delivery. Calculation of each person’s available time for the sprint.
Identification of the user stories they are committing to and those they feel they have the capacity to complete, but cannot commit to at this time. Task estimates should this be part of the team’s policy to exit planning.
Finally, the presentation to the Product Owner, and anyone commonly invited, to share the Sprint Goal and commitment of work.
Q: Preparing for an effective stand up meetings.
D: We began by understanding the word “effective.” We agreed that this meant sharing progress in the form of what was completed, what is in progress, and blockers/impediment the team members are experiencing. The second part is getting in sync for what is required for the next twenty-four hours. We also agreed that the focus was on the team for which this Daily Scrum event intends to benefit the most. However, observers, that is people who listen and learn, may benefit as well.
Now the preparation discussion. Schedule all the Daily Scrums events on or before the first day of the sprint / time box. Posting or sharing Daily Scrum observer policy. Since the Daily Scrum is about 15 minutes, the best way to prepare is to think about what each person will share in their time slot. This is particularly important for team members who cannot share in a short time box. Discussion with the team member(s) when help is required. There is no need to wait for the Daily Scrum to ask for help. It can be done in advance and rolled in to the Daily Scrum for the team to understand any impact on the next 24-hour. Updating any electronic user stories with comments and/or status changes as per the team policy. Scheduling a Daily Scrum After meeting to continue discussions on “parking lot” topics. Finally, reflect and adapt if the Daily Scrum is ineffective.
Q: Product Backlog Refinement - process to achieve
D: Not uncommon to spend two hours during the 2-week sprint time box. Maximum four hours should it be required. Session normally led by Product Owner (PO). Entire Scrum Team attends. Stakeholders can be invited should the PO need assistance.
Each session could have different agendas based on what is required. Therefore, a variety of topics, each of which a time box if required, can be included.
New Product Backlog Items (PBI) discussion?
PBI Additions, Subtracts, Questions?
Need to change the ranking order?
Further define the PBI / Decompose further
For example, the refinement session just before planning can focus on questions, sizing, and ranking to prepare for Sprint Planning. Discussion can occur outside the meeting. Use retros to discuss improvements.
Avoid executing backlog refinement work during Sprint Planning. You can find yourself lengthening a two to four-hour event to four to six-hour planning sessions.
Q: What is an EPIC?
D: EPIC, disregarding the definition of any tool, is used to refer to a large request requiring decomposition since its delivery span many time boxes and value stream touch points. Epics are a container of many smaller pieces of capability, a feature.
Feature represented by the yellow boxes in the product backlog icon, is capability required which will span more than one time box.
Finally, a feature is decomposed to define a persona/role, need, and business value to deliver a slice of the feature. It needs to be small enough to deliver a slice of the final outcome so it can reviewed and evaluated for value it delivered or not.
Q: How to write acceptance criteria?
D: Since there were no QA people to kick off the discussion, an assumption was made that using BDD (behavior driven development) would be the best long-term approach. It improves communication between tech and non-tech teams and stakeholders via their natural language and BDD tests are more user-focused since it is based on the user or system’s behavior. For example, test cases written using real examples of the actual requirements, to explain the behavior of the system. As Sabah mentioned, action – reaction. It works well when three things are considered. User Story, Acceptance Test, and use of TDD.
This approach does require some planning.
Requirement statements eventually become user stories with sufficient scope to be fully production ready. Includes any design, ux, coding, testing, etc. Do not want a user story to span time boxes.
The user story ideally uses the Persona/Role – need/reason – business value title format to communicate a need to deliver a capability.
The user story is a valid user scenario, rather than a mere test case.
The ‘given-when-then’ formula is used.
Given a certain scenario
When an action takes place
Then this should be outcome
I have seen that the outcome could be one or more things. Sent to screen, message presented, something undone, etc.
Given the User enters a zip code on the form.
When they enter fourth number,
Then a drop-down list of selectable zip codes is presented for selection.
Given zip code entry box list is presented.
When a zip is selected,
Then the drop-down list disappears and the cursor moves to the next entry field.
Cucumber is a test framework that supports BDD. In Cucumber, the BDD specifications are written in plain, simple English which is defined by the Gherkin language. Gherkin presents the behavior of the application used, from which Cucumber can generate the acceptance test cases. Cucumber is a framework developed by Ruby that can work across different technologies.
Regardless of the format used to define the acceptance criteria, avoid a laundry list of criteria which requires so much testing that the user story takes the entire time box as if a waterfall phases are being executed. We want the user story to take a couple to few days so if it can be completed independent of the other user stories. When it cannot be completed, the others can deliver the business value.
BDD encourages the team to develop, test and think about the code from the view of the business owner mindset. Ideally, the team should use TDD development – test approach.
TDD is a software development approach where tests are written before the code is written. It encourages the bare minimum of code to be written to pass the test to be fulfilled.
Run test (test should fail). If not, investigate and start again.
Write minimal code to pass the test.
Run test again.
Test failed, return to write minimal code to pass the test.
Test passed, move on
Refactor code as per coding standards and other good coding techniques.
Run test again.
Test failed, return to write minimal code to pass the test.
Test passed, move on
Work on the next user story functionality or user story.
The code will then be refactored, as often as necessary, in order to pass the test, with the process being repeated for each piece of functionality.
< thanks to the Tampa Agile SCM Meetup for the BDD education>
Though the question was on acceptance criteria, our discussion touches on the criteria and its on the user story and testing which it can impact to inject quality at many levels.
Q: Dealing with mgt when unable to meet [sprint] goals?
D: As this discussion began, everyone commented to not wait until the team is unable to meet [sprint] goals. Incidentally, this itself is a good reason to be sharing. Dashboards, risk/issue posting, board, Daily Scrum, burn down chart, and mood board are all information radiators to share.
It is also important for the Scrum Master to remind management that 100% delivery of the Sprint Goal is not normal. Therefore, discuss reasonable, predictable metric [sprint] goals targets based on velocity and identification of achievable commitment and “best effort”.
Question not discussed.
Q: What to do when people don't know what questions to ask?
S: If this was intended to discuss break the ice. Try asking the common reflection questions. What has been going well? What has not been going well?