Is our Agile plan standard? Please help validate

Question

We have been trying Scrum But for a while now and are trying to formalize it within as our own version of Agile Application Development. Here's how our current process works. There are two main drawbacks to it as it stands right now. Wanted to get input on whether you have a similar approach and if the community has any practical tips for the impediments we currently have.

Scrum team = 4 Developers, 2 QA, 1 Tech Writer, 1 PO(PM), 1 Scrum Master (Engg Dir) Release = 3 Sprints Sprint = 2 weeks

PO and customers create product backlog of user stories and related acceptance criteria 1 week Sprint planning at the start of each iteration Day 1# Estimate the Sprint backlog and agree on priority Day 2-5# Scrum team discuss stories and work on the details of each story in the Sprint backlog (get the details on the story, process flows if any, identify UE guidelines to apply, details for UI items/fields/widgets and their behavior if anything specific is required, understand acceptance criterias and create tests) 2 week Sprint with 15 min daily scrum Repeat 3 week cycle

The two major drawbacks we're having in this are; 1) The details that are discussed in the spring planning week are not captured effectively and get noted on a wiki. Since there is no standard format for capturing such details in Scrum, often time is wasted in daily scrum or subsequent meetings are required to further understand story details. Whats the best way of capturing story details for a functionally fairly complex product in sprint planning? Most of the issues seem to be around UI and developers inability to decide how screens/fields should be laid out without detailed mocks. 2) How do you anticipate critical showstopper bugs that come back from customers when team is in a sprint cycle. Currently the Dev folks have to be pulled away into supporting these Red Account issues that crop up thus disrupting the sprint.

Any inputs on how we can improve this?

Answer 1

Yep. I noted that nowhere in your process were the developers listening / talking to the actual end users. This is a recipe for failure. You cannot expect your "PO" to catch all the nuances that the actual users will express.

Developers must talk to the end users. The PO should be there as well, to document what was discovered. This is the biggest problem I see in most development projects, separation of developers from users.

Ron

Answer 2

Why are you sprint planning meetings a week long? The goal of sprint planning is to get just enough detail to feel comfortable as a team with the features you can get done and commit to doing them. This usually takes less than a day (~4 hours). The actual implementation details are discovered just in time by the devs during the sprint. That is why it is so important that they have access to the PO and the users. If you are asking where to capture the details, then you are designing to much in the planning meeting. The details should go directly into code during the sprint as they are worked out.

What would be a showstopper? The PO sees the progress at the end of each sprint (2 weeks) and then decides if the business value is enough to warrant a release. If there were any critical issues then the PO would probably not release that sprint. Hopefully you can get your PO and maybe users to look at the product on a daily basis as features are completed and thus reduce the probability of issues at the end of a sprint.

Answer 3

1. There is no "standard" Agile plan. Plans aren't important.. planning is. What i mean by that is adapt your plan regularly to reflect ground realities. Formulating a plan, having it blessed by the powers to be and then strapping on developers hasn't worked traditionally.
2. Sprint planning shouldn't go over a day if I'm not mistaken. One of the key ideas of scrum is that you don't spend too much time planning. If they do, stop and reconvene when you have better clarity.. dont trudge on.
   • Get prioritized set of stories from customer ~3 hrs
   • developers huddle to estimate ~3 hrs
   • show estimates and let customers change their bucket to reflect business needs (within sprint quota) ~rem time.

Documenting decisions:

• Get a good scribe? Someone who can type away as fast as 4 people talk.. get the core statements/decisions in a high-visibility area like a chart.. or a wiki.. whatever works for you

UX Study:

• Try to pipeline UX work. Make sure the UX people have already worked UI Details,Mock screens, workflows, etc. by the time the devs get to it. UX is working on stories for Iteration n+1 when the devs are working on iteration n. A bit difficult but can be done if UX is causing a lot of "thrashing" for you.

Bug-Duty:

• One approach is to make all bugs as regular backlog items for the next iteration. Get Customer buy-in on which ones need to go in during sprint planning.
• If that is not feasible, Trend bug-inflows, rate of fixing and plan for it. Keep x days marked away for the fix-on-demand devs dedicated for these requests.

Scope for improvement: You need a dedicated person in the "customer" role (or coach/BA who can front for the customer) that the developers can get in touch with on a real-time basis. Daily scrum meetings should be timeboxed to 30 mins and shouldn't include story "clarifications". Stick to the 3 questions - What did you do yesterday? What are you doing today? Any obstacles you need help with?
The dev or sub-team in charge of a specific story should work with the Customer/Front in case of doubts while they are working on the specific task. They are responsible for extracting out the details as part of the development effort. They can request for help from other devs who have worked in related areas too if that helps. Work together with the customer to stay on the right track.
HTH