Features, Use Cases, Requirements, Oh My!

Functional Requirements
Functional requirements express what the system does. More specifically, functional
requirements describe what the inputs are, what the outputs are, and how it is that specific inputs
are converted to specific outputs at various times. Most software applications conceived to do
useful work are rich with functional requirements. When specifying these requirements, its
important to strike a balance between being too vague (When you push the On button, the
system turns on) and being too specific about the functionality.
Its important to give the designers and implementers as wide a range of design and
implementation choices as possible. If were too specific, we may over-constrain the team and if
were too wishy-washy, the team wont know what the system is supposed to achieve.
Nonfunctional Requirements
In addition to functional requirements such as inputs translating to outputs, most systems also
require the definition of a set of nonfunctional requirements that focus on specifying additional
system attributes, such as performance requirements, throughput, usability, reliability, and
supportability. These requirements are just as important as the input-output oriented functional
requirements. Typically, nonfunctional requirements are stated declaratively using expressions
such as The system should have a mean time between failure of 2,000 hours, The system shall
have a mean time to repair of 0.5 hours, and The Smartbot shall be able to store and retrieve a
maximum of 100 weld paths
Design Constraints
As opposed to defining the behaviors of the system, this third class of requirements typically
imposes limitations on the design of the system or process we use to build the system. Well
define a design constraint as restrictions upon the design of a system, or the process by which a
system is developed, that do not affect the external behavior of the system, but must be fulfilled
to meet technical, business or contractual obligations. A typical design constraint might be
expressed as Program the welder control unit in Java. In general, we treat any reasonable
design constraints just like any other requirements although testing compliance to such
constraints may require different techniques. Just like functional and nonfunctional requirements,
these constraints can play an integral role in designing and testing the system.
Hierarchical Requirements
Many projects benefit from expressing these requirements in a hierarchical or parent-child
structure. A parent-child requirement is an amplification of the specificity expressed in a parent
requirement. Parent-child requirements allow you a flexible way to enhance and augment your
specification, while at the same time organizing the depth of detail presented. By looking only at
the parents, its straightforward to present the top-level specification in a way that is easily
understandable by the users. At the same time, the detailed child specification can be quickly
inspected by the implementers to make sure that they understand all of the implementation
details.
Note that hierarchical requirements consist up of the standard three types of requirements
functional, non-functional, and design constraints. Its only the elaboration relationship between
these requirements that is defined here.

JIRA System
Feature
Software Feature is Software Architectural Design artifact. One Software Requirement can be
fulfilled by development of one or more Software Features. One Software Feature can fulfill one
or more Software Requirements. It should be described by the Software Architect.
Requirement
Software Requirement is Software Requirements Analysis artifact. It can be functionality,
feature, performance requirement, usability requirement, design requirement, product
characteristic, etc. It should be described by the Requirements/Business Analyst.
Story
A story or user story is a software system requirement that is expressed in a few short sentences,
ideally using non-technical language. In JIRA Agile, a story is represented as an issue, and
individual tasks within the story are represented as sub-tasks.
Task
Tasks are work records or work orders that are not linked to any particular software item. Tasks
can be installation task, integration task, configuration task, management task, planning task,
reporting task, documentation task, design task, meeting, etc
Unit
Software Design Unit is Software Detailed Design artifact. It describes the smallest testable
chunk of code. Unit testing is performed by the Software Development team.
Modification Request
A Request for Correction or Enhancement in the software, raised during its operation in a
production system. The Correction in the software can be Corrective, to solve a problem, or
Preventive. The Enhancement in the software can be Adaptive, upon a client requirement or
Perfective, for improvement in the software. MRs are reported by the Software Maintenance
Department.
Change Request
Enhancement to an existing software or its part. Reported by the Software Quality Assurance
Department. The CRs can be adaptive, preventive or perfective.
Anomaly Report
AR is defect in the software or failure of the software or some of its parts. Anomalies are
reported by the Software Quality Assurance Department.
Bug
Bug is a problem which impairs or prevents the functions of the product.

Iterations vs. Sprints

All sprints are iterations but not all iterations are sprints. Iteration is a common term in iterative
and incremental development (IID). Scrum is one specialized flavor of IID so it makes sense to
specialize the terminology as well. It also helps brand the methodology different from other IID
methodologies :)
As to the sprint length: anything goes as long as the sprint is time boxed i.e. it is finished on the
planned date and not "when it's ready". (Or alternatively, in rare occasions, the sprint is
terminated prematurely to start a new sprint in case some essential boundary conditions are
changed.) It does help to have the sprints of similar durations. There's less to remember about the
sprint schedule and your planning gets more accurate. I like to keep mine at 2 calendar weeks,
which will resolve into 810 business days outside holiday seasons.
Velocity Definition
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can
be estimated by viewing previous sprints, assuming the team composition and sprint duration are
kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based
planning. Once established, velocity can be used to plan projects and forecast release and product
completion dates. How can velocity computations be meaningful when backlog item estimates
are intentionally rough? The law of large numbers tends to average out the roughness of the
estimates.
Description
The value of velocity is a percentage with a default value of 100%. If your team's velocity is
generally slow, respectively over-estimate themselves, please adjust the parameter below.
For example: enter '75' als velocity, if your team finished an amount of 75% of the issues they
have estimated within a time period. Based on this velocity parameter, planned start dates will be
calculated as planned end date minus original estimation (duration of estimated effort taking
weekends into account) multiplied by the velocity factor to stretch the timeline. The velocity
factor will be calculated internally as 100/velocity and is 1.333 in this example: 3 days effort
needs 4 working days to be finished.

TO BE QA
Proactive, Keen to details, Conversant/certified with international testing and certification bodies,
QMS knowledge in your area of specialization, solving technical quality issues amicably, team work,
understanding process standard operating procedures, making concrete and firm decisions in view of
quality, honest and firm.
Loyal to your work, knowledge, ability to take decision, and keen interest to update all QA skills
First you should practice the QA by yourself in an established system, be knowledgeable, ability
to talk decision and make a good brain storming activity in each problem that face you and finally it really
like a talent that appear in the Assiduous person
I believe, that aside from the numerous training courses available, attitude is one of the key
factors in being a successful QA Professional. I've experienced "QA Professionals" that have a alphabet of
certs behind their names, that in my opinion are not really professional in their approach. Understand that
there are gray areas in QA, not everything is totally black and white. Be the person that is willing to teach,
mentor, and help rather than the dreaded box checker.
I've said it before when this question has appeared in group discussions, but a thick skin, sense of
humor and the patience of an angel spring to mind instantly. Patiently explain "why" you have to do
things a particular way rather just telling people to do it. If people understand the rationale behind the
processes and feel a part of it, especially in a complex supply chain, they are less likely to cause problems
along the way.
It's also important to make sure people understand that Quality is something that they all need to
understand and contribute to, not something the QM does to or for them. Your role is to create and steer
the systems that contribute to the success of the company as a whole.
Don't just think about it as keeping the pretty picture on the bottom of the letterhead or the certificate on
the wall. Believe that applying the spirit of a standard is beneficial to the business, the customers and
therefore ultimately the staff who stay in a job.
Ethics, communication skills [written and Oral], product knowledge, people skills, Technical
skills, Effective decision making, presentation skills, Computer skills, and a stiff drink at the end of each
day.
Commitment-driven iteration planning - Discuss the highest priority item on the product backlog:
Decompose it into tasks

Estimate each task

Whole team estimates each task
Ask ourselves, Can we commit to this?
If yes, see if we can add another backlog item
If not, remove this item but see if we can add another smaller one.

AGILE TIPS AND TRICKS

Do retrospectives

Get competent team members

Continuous integration from day one.

Use Flowdock or similar tool for digital communication not Skype

An endless backlog is waste

There is no value in tracking all bugs. It is ok to forget a bug which was not important
enough to fix right away.

Pull request are a good way to manage peer reviews

We like peer reviews

Definition of done. Have one.

If you are faced with a distributed team rotate people so that everybody personally knows
and regularly works with all team members/PO/SM face-to-face.

Shorten sprint length if the scope doesnt seem to be stable.

If the sprints are unstable, but you have a very stable flow you can consider switching to
Kanban.

To reduce a story in size ask what is the value of the story is and how can we deliver 80%
of that value (in a shippable way of course).
o

To reduce more, get inspiration from e.g. a printed Splitting Story Flowchart.

Dont release on Friday.

Create a table which shows who is present and who isnt for the coming week

The daily standup shall not exceed 15 minutes, unless you decide its ok of course :)
(Dont decide too often, and only for learning purposes so that future Dailies are less than
15 minutes)

To keep a daily short, don't discuss in depth, save that for after the daily.

An alternative for daily standup (what did/will I do) is what did I learn, what do I need to
learn today and how you can help me

A second alternative is 1) What do others need to know about the things I did yesterday,
2) What can I get from, or how can I collaborate with others to get things done effectively
today, 3) What is blocking my effective work?

The Scrum Master should have time to observe (eg not busy with 100s of tasks)

A good PO is very important. Take some time in the beginning of the project to identify
the constraints the PO has in terms of availability to the team, authority to make scope
and budget decisions, domain knowledge, access to stakeholders.

Weekly smiles (sharing your mood) within the project team are good

On site is the best place to do a project

Index cards are great for planning sessions, any digital tool sucks.

Agile is a mindset not a rigid method.

You can break any rule if and only if you understand why the rule was there in the first
place.

The team should own the tools it uses.

Any tool that forces a process on the team limits the capability of the team to optimize
creating awesomeness

Minimize the time and effort needed to make a release

Specification by example automate them

Pair-work

Treat ALL specs as speculation

Estimations are not commitments, they are estimations (i.e. just guesses, predictions)

face-to-face constructive feedback is good (5 minutes between all team members twice a
year)

6 Tips for Good Scrum by Martin Harris

If you are doing these 6 tips, then you are doing very well and are likely to get better overtime

Love your product owner. The group agreed that the product owner should be part of
the team. Include them in the meetings and get them involved. Its possibly the most
important thing you can do for success in scrum. A fully integrated product owner will
spot early on if the stories do not match their expectations. They negotiate the definition
of done for a story. They are on hand to answer questions during the iteration removing
waste and improving understanding of the stories. The product owner decides if the team
has finished stories at the demo. Working closely with the product owner can avoid going
adrift and missing your goals, saves a lot of stress when things hit a rough patch as they
get to see the problems first hand. We agreed that this point can not be understated, if you
do nothing else do this.

Run Retrospectives. Its very important to take actions away from a retrospective. Be
realistic though, your never going to solve them all, so ask the team to priorities them. If
your doing the retrospective right your product owner will be there to help with
prioritisation. If you find something very big lands at the top, split it down into stories.
Otherwise pick one or two that the team feel strongly about and turn them into stories.
Make sure these stories are included in the next game planning sessions and make it into
the iterations. If you have adjustments to the process you can implement these straight
away, but experiment with it, and try to measure the impact of changes, you might not get
the process right first time. Commit to doing them and then deliver.

Ask your team to Pair Code (My definition of Pair Programming: A technique
to increase development throughput by maximizing review
coverage, reduction in faults leading to increased software quality
and less effort in downstream processes such as manual testing and
product maintenance.). The XP technique of two programmers working on the

same task. It was agreed that there are different kinds of pair coding and that they all
have a place, but the one we are talking about here is where two equal programmers work
together to improve quality and throughput. Dont be dogmatic, let the team decide how
much work should be pair coded.

Setup Self Directed teams. Self directed teams have been proven to be more efficient.
We discussed the role of a scrum master in a self directed team. Its very important that
the scrum master does not tell the team how to work, or how to go about completing the
tasks. The scrum master does not plan or allocate tasks. The empowered team needs to
work out what the tasks are and find out how to finish the stories. The scrum master
should spend his efforts removing blocks for the team, checking quality. Its important for

the team and scrum master to spot if someone is not completing their work for whatever
reason, but a strong team will sort out those kinds of issues if truly self directed. We also
decided that to be empowered you need to make the team multi discipline. Include
testers, user interface designers etc to remove hand off waste and increase team
knowledge. With role diversity comes better decision making.

Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.
Delivering builds trust in the team and the process. Classic ways to miss delivery
include: Failing to produce a strong definition of done. The definition should include the
programming, integration, testing and setup tasks. In fact everything required to get that
task ready for delivery. Another way to miss delivers is to fail to demonstrate at the end
of the iteration. You may think your done, but when the product owner sees the work for
the first time they may request refinement. If you have kept your product owner close
then the demo is likely to be painless. No power-point slides please, only real working
software in the demo! So commit and then deliver what you commit to.

Co-locate your team. The group defined co-location quite tightly. Co-location is not
putting everyone in the same office. Its putting the team members next to each other in
the same space. Intra team communication does not happen with the team scattered
around an office. You should be able to turn around and join the stand up meeting. This
closeness, speeds up the myriad of tiny important messages that pass around the team.
Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea. If your doing these, then your doing
very well indeed, and are likely to get better over time.
So another excellent meeting, a few more beers and I headed home enlightenend, well fed and
slighlty merry. Why not come along to the next one, we could use your input.
http://zenexmachina.wordpress.com/2012/03/30/10-tips-for-adopting-scrum-to-save-yourproject/