Agile at Revelry - Githubissues

Read this: http://revelry.co/lean-agile/

Note: this document is descriptive, not prescriptive - we're always experimenting with ways to refine the way we work, so not every project will reflect this 100%.

Questions:

What is a sprint?
What is a user story? What are the parts of a user story?
What are Acceptance Criteria? What are some examples?
What is the function of a business rule?
Why do we add sketches or screenshots?
What is planning poker? Why do we do planning poker? When do we do planning poker?
How do we start new projects?
Who is the Product Owner? What is their job?
How do we "work" issues?
What is QA? How is it different than UAT?
What is a standup? What does an engineer do during the standup? What are some things that don't happen in a standup?
What do we do at the end of a sprint?
How would you handle an issue or project that starts to go bad?
What is Waffle?
Who is Lintron and what is his job?
What other tools do we use?

Answers / notes for questions regarding Agile at Revelry # 1

What is a sprint? A. It is a set amount of time to work on planned work. Typically last 1 or 2 weeks. Revelry sprints are 1 week intervals
What is a user story? What are the parts of a user story? A. User stories are objectives a user should be able to achieve with each feature or product. Instead of defining that a product should "just work," a user story defines success "when a user can do x."

The parts of a user story are Acceptance Criteria (AC), a specific written format (to be able to quickly digest or understand it), and a score denoted by a number in the Fibonacci Sequence. Acceptance Criteria: this should be unambiguous and written in the format of Given a specific state, When I do a specific thing, Then this specific thing happens. Format: Revelry's formatting for user stories is slightly different than normal. Revelry typically includes business insights to help clarify objectives. This allows the entire team to understand how this specific feature fits into the larger whole application/process. They're written with a format of User Type-Feature Bucket/Epic-Action or Result. These stories then become specific issues assigned in Github. Score: Revelry uses the Fibonacci numbers 1-13 to assign to stories, with increasing values indicating increasing complexity. Important of note, the stories do not measure time to complete a story, merely its overall complexity.
What are Acceptance Criteria? What are some examples? A. Acceptance Criteria is the objective completed by the user story. Anyone on the team can define AC, but the Product Owner (client) must sign off on them. The AC will go into the Github issue in the form of checkboxes. Examples: Typical Agile: As an admin I would like to filter users by most recent login. Lean agile: Admin - Reporting & Analytics - Filter Users by Recent Sign In This Lean Agile statement follows the alternative headline format used by Revelry: "User Type - Feature Bucket/Epic - Action or Result"

Continuation of questions for Agile at Revelry # 1:

What is the function of a business rule? A. Business rules are generally a set of statements or conditions that help guide actions and activities. These are set by conditions/criteria and typically help inform the development of policies and processes, including defining requirements for services and projects. They are typically foundational and therefore static. Example: BR # {Value}: All Masters' Degree Programs must include the development of a thesis.
Why do we add sketches or screenshots? A. Revelry tries to include sketches/screenshots/diagrams whenever possible. This adds more context for developers and designers as they develop stories. Visuals make it easy to be on the same page as our clients for story rationale and connection to the larger process/application
What is planning poker? Why do we do planning poker? When do we do planning poker? A. Planning poker is a standard way of figuring out the complexity of a story via a democratic voting process. We do planning poker instead of assigning a point value because every member of the team should have input on the complexity and difficulty of the task. Some may find a task easy, while some others may find the same task very complex. Planning poker allows for the average score to be calculated fairly and without outside influence. We do planning poker after the ticket has been drafted and approved by the Product Manager or Product Owner. At that point in the ticket process, it is ready to be scored.

How do we start new projects? A. Revelry starts a new project with a discovery sprint. This allows us to clarify business objectives, project goals, and user needs. The entire integrated team works on this discovery sprint (Producer, Designer, Engineer, QA, Client/Product Owner). The completed Project Brief lists details of who we are building for, what problem we are trying to solve, and why that problem matters. We then run our starter stories scripts, allowing for both easier and standardized project setup tasks. The Slackbot script creates the project in Github, adds the Project Brief template, hooks up Agile tools, sets a bunch of permissions, and generates the first batch of stories. We then invite clients to the slack channel so that the entire team sees any and all conversations, allowing full transparency.
Who is the Product Owner. What is their job? A. The Product Owner is usually a point person on the client's team who serves as the ultimate decision maker on anything related to the product. On most projects, the Product Owner co-writes the user stories with Revelry and is as much as possible involved in the day-to-day of the sprint. If the client can't play the role of a Product Owner, we can provide that as a service, bringing fully written stories to the client for approval and user testing.
How do we "work" issues? A. We use Github for distributed version control and story tracking and using kanban to visualize progress (which also connects to Github). The story sits in the Backlog until we move it to This Sprint during the sprint kickoff. When an engineer starts working a story, they move it to In Progress. As they complete the AC (Acceptance Criteria), they mark off the checkboxes. Once all AC is complete, the code is scanned by Lintron which is an automatic style-checker bot. Lintron catches style and logic issues. After the engineer has addressed Lintron's notes, they move the story to In-Review and assign their PR (Pull Request) to a different Revelry engineer that may or may not be on the same project. After the code is reviewed by that second Reveler, the story is deployed to internal QA. Revelry uses Codeship for automatic deployment and continuous integration. If QA finds any issues with the AC, they uncheck the relevant boxes and send the story back to the engineer. Potential Bugs: in the case of a large story where just one AC is missed, we close the story and log a new bug. If an edge case arrises in QA that isn't represented by AC, we log a bug. Once QA is done we move it to UAT (User Acceptance Testing). This is one of our client's most important jobs. They should be using the systems every day. If there are issues, they send it back down the chain to the engineers. Stories coming back from UAT are the highest priority so we work on the immediately! After UAT is completed, we immediately ship the new features to production via automated deployment.

What is QA? How is it different from UAT? A. As (verbosely) said above, QA (Quality Assurance / Testing) is internal testing done by Revelry's QA team. QA happens in the process before the story is given to the client for UAT (User Acceptance Testing). QA is specifically checking for completion of the AC and any errors/bugs. Once QA has finished, they will pass the story onto the client for UAT. One of the client's most important jobs (besides helping us write user stories) is to do UAT and use the system every day. If there are issues, they get sent back down the chain to the engineers (Where it is given the highest priority for fixing). When the story is complete in UAT, we immediately ship the new features to production through another automated deployment.
What is a standup? What does an engineer do during the standup? What are some things that don't happen during a standup? A.
Our daily standup meetings happen in Slack, and are completed in 10 minutes or less. We use a reminder command to run our scrum meetings automatically. Each person answers the following questions: What did you do yesterday? Include issue number. What are you planning today? Include issue number. How are you blocked? Ask for help and set reminders. We note blockers and take them offline to be addressed. Do not solve problems on standups! If we need to hash anything out face-to-face, we quickly jump on a Zoom call. All updates should reference their specific issue number! That way by the end of the meeting, we've updated all the stories to reflect their current status.
What do we do at the end of a sprint? A. During the week, we have also been writing new stories for the next sprint. Often we will run a session of planning poker at the end of the week to prepare for the next sprint kickoff. Every other sprint, the team has a retrospective conversation. The team discusses what went well and what went poorly, with specific tactics to improve the next sprint (i.e. improvement through better communication or velocity)
How would you handle an issue or project that starts to go bad? A. The problem-solving is handled primarily by the project's Producer on the Revelry team. However, as an engineer, when running into problems: Immediately ask questions in the implementation Slack channel. Assume it won't be answered and do your own research for 30-60 minutes. If you have made no progress, at-mention ping someone to get attention on the problem. For stories you won't finish by the end of the sprint: It happens, don't panic! Alert the #firedrill @channel in Slack as soon as you realize a sprint commitment is at risk. Any stories that aren't in QA 24 hours before the end of a sprint are at risk of rolling over. Stories rolling over are top priority for the following sprint and no new stories should begin until the previous rolled-over stories are complete. When a client asks for a change or a new feature mid-sprint: This could happen, but by sticking to the above standup process and policy, it's easier to avoid. Firstly, any AC changes or features must be addressed immediately outside of a standup. If it's a single update of AC or a small addition, the Producer will often update the existing story as long as it doesn't affect the difficulty score of the story. If the change is big enough, the PM will write a new story. The original story is now a dependency of the new story to be created and the two should be linked via #issuenumber. Typically if the request is a new feature it will get added to the top of the priority list for the next sprint. For the 1 out of 10 times that we really need to get the new story added to the sprint, we'll do lots of handwaving to point out it risks bumping an existing story off the sprint commitment.

What is Kanban? A. The Kanban functionality we use (through Github) is a replacement for Waffle which is now deprecated. Kanban is a way to visually track the progress of stories to be able to tell how "agile" the teams are moving and the process is proceeding. Revelry's typical Kanban board is sorted by project, then has several categories on the board that the stories are broken down into. The story sits in The Backlog column of the Kanban board until we move it to the This Sprint column during the sprint kickoff. When an engineer starts working on a story, they move it to the In Progress column. When it's ready for PR merging, it moves to the In Review column. Next there is a QA column, then the UAT column, followed by the Done column which comes last.
Who is Lintron and what is his job? A. Lintron is a PR (Pull Request) bot that automatically checks PR's for style and logic errors/issues, freeing up engineers to use PR's to provide substantive feedback instead spending time correcting minor issues. Lintron listens for PR webhooks, then retrieves the PR and relevant files from Github. It runs through pre-determined linters (determined by the file extension) then posts the results in Github next to the line of code in the diff. The source code is available on Revelry's Github repository.
What other tools do we use? A. Besides the already mentioned tools in this issue (_Lintron, Waffle??), our main tool stack is the following: Github for story tracking. Kanban for automatically-updated visualization of issues and the process. Slack-based standups for automation/ process speedup of the standup process. Codeship for automatic deployment and continuous integration. /Poker bot for efficient story scoring in Slack. Issue Bot for creating Github issues from within slack quickly and efficiently.

BenRongey / BenApprenticeship

Agile at Revelry #1