When do you do design and analysis with SCRUM?

[Greg]

This one is confusing me with SCRUM as I read different answers when I
Google.

Mature application, in production over 2 years. We currently have a
Product Backlog. Lets says there are 50 Business Requirements in the
Product Backlog.

SCRUM says we prioritize the entire Backlog. We then select the
highest priority requirements to work on first. We get a LOE on these
from our development team. To keep it simple, lets say 10 are high
priority and the team estimates 7 hours per requirement, 70 hours of
total work.

Does the 70 hours include development design time? Does it include
system analysis time? Or is that done at a different time? When does
the software archtiect get involved, the person doing wireframes and
mockups, the design role..is all of this included in the 70 hours? If
I understand SCRUM this time is included in the 70 hours.

When in the 70 hours are we asking the development team to look at the
next set of requirements, the Mediums from the first cut, and how is
that time accounted for with SCRUM? It's a distraction to the
development team if you do this during a Sprint.

I know SCRUM says to plan 1-2 sprints for production bugs fixes. That
is in a perfect world. If we have a production critical failure in the
middle of a sprint that must be resolved, say we are storing bad data,
how does SCRUM account for this?


I am ready to get on board with SCRUN, it's the details I am
struggling with.

Thanks

[ronjeff...@gmail.com]

All time needed to do a backlog item goes into that item. Backlog grooming is not a backlog item, but is a necessary overhead. Figure about 30% time to start, adjust from there. It is done during the Sprint and if it's a distraction you are all stressing too much. Do you find meals, talking about the game, and such to be distractions, too?

Distracting or nit, it is vital. It is in this period that the team gets their head up, sees what is coming down, guides PO, plans example and tests for next time, and so on.

Vital.

Ron

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>

[Jan Beaver]

Design and analyze in slices, doing just enough of each to build the
stories in the Sprint backlog. "Just enough" does not mean *neglecting*
design and analysis, however. Instead of seeing design and analysis as
separate steps, each ending with a hand-off, do them throughout the
course of development (inside of Sprints) and refactor to keep the code
up-to-date with the current design.

Planning, as Ron described, is also continuous, incremental, and
absolutely vital.

I haven't seen anything in Scrum that calls for bug-fixing Sprints --
quite the opposite actually. Some organizations choose to do that,
although I don't advocate that approach. If you have a backlog of
production defects to work through, one approach is simply to allocate a
certain percentage of your team's capacity (velocity) to defect fixing -
using a bug-bucket story of a fixed size, for example. Analyze your
history with production-critical defects and allocate the necessary
capacity to deal with them as well. If nothing happens during a given
Sprint, make sure there is a story or two ready to pull into the Sprint
instead. Hopefully you will use automated testing, TDD, and other
techniques to improve quality so that you can actually pay off your
defect backlog and other technical debt.

If you can, arrange training for yourself and your team/teams. A good
training class can do much to clear up the confusion you are
experiencing and help you get started on the right foot.

Cheers,
Jan Beaver, PhD, CSP

[Dan Rawsthorne]

Scrum Teams do two things: they do work and they get ready to do work.

The work they do comes from the Backlog, is usually documented as
stories and sized in Story Points, and there is Velocity associated with
the work. There is many different kinds of work to get done: there are
development the stories that include design, coding testing etc. (these
include new bugs found in the system); there are maintenance stories for
other systems; and there are Chores like re-factoring, installing tools,
and so on. basically, anything that's not included in the "getting ready
for work" discussed in the paragraph must be done in the form of Stories
and prioritized with the Backlog.

Getting ready for work consists of time-boxed activities that are part
of the Team's process. For a Team working in two-week Sprints these
activities might be: two hours of a Planning Meeting, two hours in a
Retrospective, two hours of a Sprint Review, 15 minute Daily Scrums, and
four hours of Grooming a week (which I like to do in two two-hour
Grooming Sessions). Through its self-organization the Team can add other
time-boxed activities as part of its process � but that's a discussion
for another day. :-)

What we're talking about in this thread is Grooming, which is finding
the Stories and making them actionable in order to take into Planning
(it also includes some prioritization, so Grooming can be thought of as
a natural extension of Planning...). Sometimes four hours of Grooming a
week isn't enough because you're in a phase of development that
naturally requires more exploration and analysis. In this situation I
recommend Grooming Stories, which are sized in Story Points and usually
time-boxed. Some coaches recommend just doing more Grooming Meetings,
but the reason I like to do them as Stories is because additional
Grooming Meetings subtracts time from the time for doing the work - and
I think this is a problem because it skews the Velocity - so it's my deal,,,

Hope this helps... Dan ;-)

[Lv Yi]

I once shared my understanding through this small article,
http://www.scrumalliance.org/articles/149

- Yi

[Greg]

So by the time you have the Release Meeting, most of the design and
analysis has been done; any additional design and analysis is done
during the Sprint?

I assume the developers are participating in the pre Release Meeting
Design and Analysis?



On Feb 12, 9:08 pm, Lv Yi <yi...@yahoo.com> wrote:
> I once shared my understanding through this small article,http://www.scrumalliance.org/articles/149

[Kurt Häusler]

No. I would not expect much analysis and design to be done at the
release planning stages.

I would suggest modifying the way you think about analysis and design,
you may need to unlearn what they mean in a traditional sense.

In traditional heavyweight software development models, these steps
are basically converting documents into other documents, that quickly
become irrelevant. Scrum just doesn't need all that overhead, as the
developers are supposed to talk to the customer or the customer's
representative just before they need to, which might mean one
conversation before or during backlog grooming, and one conversation
just before development.

Now requirements analysis is often required, but it looks different in
agile development than it does in more traditional, document heavy
processes. There is a focus on a small number of automatable
acceptance criteria supporting ideally a simple, small requirement
often in the form of a user story. Pages of documentation are
undesirable. In fact there is a focus on using small cards because
there is limited space, and endless lists of acceptance criteria
should be avoided. If the backlog grooming process really discovers
that many acceptance criteria are required, then the requirement will
be split into several smaller PBIs.

As far as design goes, didn't Jack Reeves clear this up in the 90s?
Design is what the developer does when he begins to program. Design is
the source code. The idea of some separate, thinking, expensive
"designer" designing software with diagrams, to be handed off to the
dumb, cheap, programmer to be typed in is obsolete.

Back to the question regarding release planning. The Scrum Guide says
that it is optional. It discusses "turning the vision into a product"
which is a pretty high level discussion. Topics include:
Goal of the release
Highest priority backlog items
Major risks
Overall features and functionality.

I would expect a small number of PBIs to be involved, but I would not
expect estimates, or acceptance criteria for them, at least not to any
detail. Those issues get cleared up during backlog grooming.

Most of the planning should happen at the sprint level, doing too much
at the release level undermines the short feedback cycle of the
sprint.

[Vernon Stinebaker]

Nicely written Kurt.

Sent from my iPhone

[Nikita Gorshkov]

Yeah, that's why we can thank that approach for the eye-bleeding look of the 90s web. Unfortunately, that approach does not work. A developer (on average) does not have the required skills for actually designing something. That is why web design in a good sense exploded in the beginning of 2000s, and design became seen, at last, as a key element in product development. 

Right now this can be worked over from the perspective of a frontend developer who might combine the sets of skills -> which is a good thing, since design became a dynamic and changing entity, that cannot be sustained through static formats, such as images. But nevertheless, design should be considered as a separate phase of a feature, necessary to deliver business value. 

To answer the original question - design should go into the ticket itself. Perhaps not a perfect approach, but one that works for me -> grooming and planning in larger amounts of stories with the latter stories down the list specified with analysis and design requirements, which are then expanded and moved to the next sprint fully developed. 

[Ron Jeffries]

Nikita,

On Jan 26, 2016, at 5:15 AM, Nikita Gorshkov <feam...@gmail.com> wrote:

To answer the original question - design should go into the ticket itself. Perhaps not a perfect approach, but one that works for me -> grooming and planning in larger amounts of stories with the latter stories down the list specified with analysis and design requirements, which are then expanded and moved to the next sprint fully developed. 

Ticket? Please explain “ticket”, what it is, how it is used in Scrum.

Thanks,

Ron Jeffries

ronjeffries.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Leonhard Grugl]

Nikita,

could it be, that you are mistaking software design (which the previous posts were about) with screen design? Please, don't understand this as criticism to your post! You're right bringing up the issue of screen design and I do, to a certain point, agree with you, that many software engineers would rather not bother with screen design. What works for us (I'm in an HMI development team), is to have comprehensive design guidelines which were made by user experience professionals. These professionals also developed a set of controls which follow these guidelines in means of their look and feel. Adhering to this makes it possible even for the not so "aestethically gifted" engineer to produce interfaces which match the identity of the product. And if there are visual flaws here and there, we usually get to rework these in a subsequent iteration. By the way, it is possible to get this guidelines and resources (control library, etc.) without needing to do it all up front, which would not be very agile and probably delay the project: Depending on the technology used (we use WPF), it is very reasonable to start the UI design phase with only the basic, but mandatory guidelines (such as which control types shall be used for which kind of interaction, basic navigation design, kinds of user input, rough sizes of controls, ...). Software engineers can then start to implement functionality and screens, while the professional designers iteratively "skin" the application. In the best case, this means periodically exchanging template resources, in the worst case, it means to throw away a view and make a new one (hooray for software design with views separated from model/logic - we adhere to MVVM).

And please let me say, that I'm pretty sure, that on an "average" team, there will be one or the other engineer who does have the artist's gene.

Now, getting back to the original question, I agree to what has been said about grooming (we call it "refinement", BTW) and stuff. In addition to that, we use a couple of other approaches to canalize the design and architecture efforts. Most of the times when we struggle with the refinement not to be sufficient is, when stories are too big or when there is too much uncertainty about how to do it. You may say, if it's too big, break it down - which is correct, but sometimes this requires some more focused teamwork to do. In that cases, we allow ourselves to plan stories, which consist of conceptual work, even though this is somewhat against SCRUM, since it doesn't directly deliver business value. Nevertheless, we find it a big advantage to also include such tasks in planning, think about how we should do it (workshop, concept with team review, spike, ...), but then leave it up to the self-organized team who takes the tasks and does the coordination and moderation. For stories, which we are pretty sure will fit into the sprint but bare a certain amount of uncertainty, we plan "task explosions". This means, the story is usually being broken down into at least a conceptual task (usually with mandatory four-eyes principle) and an explosion task, which is a placeholder for concrete tasks emerging from the concept.

After all, this works pretty well for a fairly long time now, at least in the context of the HMI only.

But, since our product (a CNC machine) involves other disciplines as well, we are currently in the process of establishing an architecture unit (formed by demand as a horizontal function in the matrix organization), which should deal with high level architecture definitions based rather on product design than on actual feature to story breakdowns. Got the idea? We'll see how this works out...

Regards,

Leonhard