Defining work - Amazee Agile Agency Survey Results - Part 6

This is part 6 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about team communication & process. This time let’s focus on defining work. Who is involved in defining work and which tools are essential for organising your work?

DEFINING WORK

When asked about who is involved in defining work, we asked about which roles would be included in different phases of the ticket process.

• “Creating tickets” is performed by these roles ordered by a number of selections: “PM / PO Proxy”, “Any Developer”, “Lead Developer”, “Client / Product Owner”, “UX/Design” and finally “The entire team together”.
• “Refining/grooming/specifying tickets” is performed mostly by “Lead Developer”, “Any Developer” and “PM / PO Proxy” rated equally high, then “Client / Product Owner” and “The entire team together” rated equally high and finally “UX/Design”.
• “Estimating tickets” is done by “The entire team together” followed by “Lead Developer” or “Any Developer” rated equally often, then “UX/Design”, “Client / Product Owner” and finally “PM / PO Proxy.”

It looks like there is an apparent tendency for Developers or Lead Developers to be involved in all parts of defining the work. It also makes sense that Clients / Product Owners or the internal counterparts in the agency PM / PO Proxies do participate in defining the work but don’t participate in estimating. For us at Amazee, having the entire team estimate is essential to make sure there is common knowledge about the problem space and that we can get multiple views to validate our understanding of the client’s requirements. Any of our developers can take a leadership position in a particular project, that person would then be tasked to specify tickets together with the Project Owner (PO) or the client directly, and get estimated by the team later on. Survey contestants also shared some additional insights about defining work/tickets. I’d like to quote a few of them.

"We have in each team an estimation engineer, scrum master and an architect. Everyone is responsible for doing architectures and estimations, bit the QA goes through these roles. The scrum master is responsible for the 2 weekly process while also being part of the development team." "Involvement across ticket lifespan evolves as project matures." "Being the most verbose possible." "You have not mentioned Acceptance Criteria. This is written in collaboration between our QA and Stakeholders client side, ideally the product owner." "Again - depending on the project/the client and the PM. We had clients that created and defined tickets together with the PO at our side, so that they could be specified during planning and then estimated by the devs. Sometimes PM is doing it, and sometimes this is done by the lead dev (if PM/PO isn't able to do it). Estimation depends a bit on the time pressure and the team size. If possible we estimate with the whole team. But sometimes we only have the lead dev and the dev who is going to implement the feature estimate."

**ORGANIZING WORK **

We also asked which tools were how important when it comes to organizing work. As shown in the illustration above, the ones that had the most apparent tendency towards their importance were “Sprints”, “User stories”, “Acceptance criteria” and “Tasks”, whereas the graph looks more indifferent when it comes to “Epics”, “Definition of Done”, “Definition of Ready” and “Releases/Versions”. For us at Amazee, two-week sprints are a crucial instrument for planning and deciding about the priorities of our work. We don’t use User Stories all the time but feel like they are a good way of allowing clients to explain their requirements to the team effectively. Acceptance criteria (AC) are a must for anything that the team will implement - this can be on the user story level or the task level. Our teams also follow a definition of done to make sure that everything is in the right place when it comes to browser testing or on which environment results should be available. Recently, we started using Epics to group requirements that we had earlier on put into components in Jira. This allows to easily track the progress per Epic which is a neat feature in Jira. Releases/Versions aren’t used too much in the teams I work with. How do you define your work? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us. Stay tuned for the next post where we’ll look at estimations.