scrum - Is our agile plan standard? -


we have been trying scrum while , trying formalize within our own version of agile application development. here's how our current process works. there 2 main drawbacks stands right now. wanted input on whether have similar approach , if community has practical tips impediments 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 , customers create product backlog of user stories , related acceptance criteria.
1 week sprint planning @ start of each iteration

  • day 1# estimate sprint backlog , agree on priority
  • day 2-5# scrum team discuss stories , work on details of each story in sprint backlog (get details on story, process flows if any, identify ue guidelines apply, details ui items/fields/widgets , behavior if specific required, understand acceptance criteria , create tests)
  • 2 week sprint 15 min daily scrum
  • repeat 3 week cycle

the 2 major drawbacks we're having in are:

  1. the details discussed in spring planning week not captured , noted on wiki. since there no standard format capturing such details in scrum, time wasted in daily scrum or subsequent meetings required further understand story details. whats best way of capturing story details functionally complex product in sprint planning? of issues seem around ui , developers inability decide how screens/fields should laid out without detailed mocks.
  2. how anticipate critical showstopper bugs come customers when team in sprint cycle. dev folks have pulled away supporting these red account issues crop disrupting sprint.

any inputs on how can improve this?

  1. there no "standard" agile plan. plans aren't important.. planning is. mean adapt plan regularly reflect ground realities. formulating plan, having blessed powers , strapping on developers hasn't worked traditionally.
  2. sprint planning shouldn't go on day if i'm not mistaken. 1 of key ideas of scrum don't spend time planning. if do, stop , reconvene when have better clarity.. dont trudge on.
    • get prioritized set of stories customer ~3 hrs
    • developers huddle estimate ~3 hrs
    • show estimates , let customers change bucket reflect business needs (within sprint quota) ~rem time.

documenting decisions:

  • get scribe? can type away fast 4 people talk.. core statements/decisions in high-visibility area chart.. or wiki.. whatever works

ux study:

  • try pipeline ux work. make sure ux people have worked ui details,mock screens, workflows, etc. time devs it. ux working on stories iteration n+1 when devs working on iteration n. bit difficult can done if ux causing lot of "thrashing" you.

bug-duty:

  • one approach make bugs regular backlog items next iteration. customer buy-in on ones need go in during sprint planning.
  • if not feasible, trend bug-inflows, rate of fixing , plan it. keep x days marked away fix-on-demand devs dedicated these requests.

scope improvement: you need dedicated person in "customer" role (or coach/ba can front customer) developers can in touch on real-time basis. daily scrum meetings should timeboxed 30 mins , shouldn't include story "clarifications". stick 3 questions - did yesterday? doing today? obstacles need with?
dev or sub-team in charge of specific story should work customer/front in case of doubts while working on specific task. responsible extracting out details part of development effort. can request other devs have worked in related areas if helps. work customer stay on right track.
hth


Comments

Popular posts from this blog

c++ - How do I get a multi line tooltip in MFC -

asp.net - In javascript how to find the height and width -

c# - DataTable to EnumerableRowCollection -