code | 2017-04-10
10x your Agile results and being a development god - Sprint work, demo, and standup
My goals for a sprint
- Independant Sprint Work
- Little to no hand holding <- Shine
- 15 minutes then ask, use teamates to drive performance
- Follow up on code review suggestions
- X - X+1 stories in a sprint
- Find blocking items
- Before leaving the day, write what I worked on and rough estimate of tomorrow.
- Morning of, check if there are any fires.
- Make people smile by being the first to say Hello
- Be the first to say Hello
Transforming to Agile is usually a process, learning from mistakes and listening to what each other is working on. But there are a lot of little aspects that make it productive. I've found these things out the hard way, I'll list them out below
- ETA on completion
- Move to correct queue (Backend team, QA, PM, etc)
- Soft handoff, tell them I moved it to their queue, and Why
- Note possible related stories could also be blocked
- Don’t wait to email the group or talk to team if something is incorrect
- “I found a blocker from x and contacted individual’s name, they...“
- Update Story with their comment
- Examples: Acceptance environments are down, Incorrect data, Dependancy on SQL or API which wasn’t stated in requirements, test cases were incorrect
How to demo stories to a client
Demo’ing stories is the accepted stage in JIRA, this can be used to either assign the work to the business owner and have them accept the stories through the sprint. Another way for the business owner accepts stories is for the team to demo the stories. This involves a bit of involvement from the development team as they walk the business owner / client through the story, stating test cases that we went through and showing them where exactly the fix was. It’s a bit of overhead but allows ownership of the stories and brings up important questions.
“One of your devs always shows me a lot of stories while other developers show me one or two. Why is that?”
- Prepare acceptance criteria - a title usually isn't enough to describe the story
- Setup screen share, so your talking about the story your showing and not relying on them to follow your instructions
- Prepare document using JIRA filter for my list of stories to Demo
- Add a brief, 1 sentance description that explains why this was important.
- Ex: impacts to the user? Adding data points to the page? Error affecting X users because of Y
- State edge cases and things that were specifically tested. If I show 3 views of the same page, the first is the most popular way to view the page, the other two are edge cases and I explain why this is important.
- List bugs that were found, why they happened and how they were addressed. I do this 50% of the time, usually to help show edge cases
- Speak the steps to reproduce the story clearly and confident, "Scroll down","Click on.."
- Try to really show off to client. It’s sometimes the only time you get to show off your work
- If a bug is found during demo, proactively see it and say it. It depends on the error, but this may prevent the story from making it part of this sprint.
Important note: this is why you should reproduce your stories before demoing. Going through QA test cases and knowing what specifics your going to show will prevent this from happening and you’ll see this issue sooner.
- Take apart requirements
- Find Problems and Causes
- Identify Solutions
- Dependancies on other tickets or similar stories that touch the same component or area of the page?
- Point estimation
- Effort to test
- Complexity of development
- Challenge if story is small and precise enough
- Can we start today?
This is crucial because sometimes business owners like to prioritize sprints with stories they just found out about and don’t like waiting a couple weeks for the next sprint. So acceptance criteria isn’t fleshed out and we’re partially blocked. This isn’t a huge deal if the missing requirement is “When should we start this task?” or “Whats the text this error message should say”, but it adds back and forth to the story, and more effort because I jump into it and have to jump back, making sure I test my previous work before handing it off. Personally, I don’t prefer it because I tend to miss test cases.
The stories in the sprint are stories the team WILL get done, it shouldn't be "they'll have a less likely probability of getting the last X stories done"
Considerations for the current sprint
- Stretch / stories added after the sprint that we’re working on are stories team MIGHT get done
- Considerations - Outages - Who’s out from the team? How does it impact our ability to deliver these stories
- Are there a lot of in-house QA Heavy Stories (need internal tools)?
- Are there stories that offshore QA can work on?
- Is there a release soon? If so, let's ask offshore QA to perform regression
- Strive to accomplish x points
- Find blocking items right away
- Test SQL or API and see if it has incorrect data or non-existent fields
- When story is complete, go through checklist
- Can we refactor this? How could it be improved?
- Is any logic confusing to me, jumping into this the first time?
- Comment on confusing logic or add //TODO on future development areas
- Ask QA if you can bring a story into the stretch
- If they aren’t comfortable with Development getting really far ahead, then it’s time to work on items your intersted in.
- Side Projects, Quarterly Objectives, Blog posts about what you worked on
- Review previous sprints action items
- Bring up one to two team members shining moments
- Why were they crucial to this sprint?
- What did they share with you, helping to complete a story.
- My goal is to lift team members up, allow them to be noticed.