agile scrum and tech docs survey - Dashboard
7,107
visibility Viewed
61
Total Responses
61
flag Completed
100%
timelapse Completion Rate
0
do_not_disturb_on Dropouts
25 mins
access_time Average Time
 
Countries Responses
US 52.46%
CA 6.56%
RU 6.56%
SE 4.92%
DE 3.28%
FR 3.28%
GB 3.28%
UA 3.28%
BY 1.64%
NZ 1.64%
PH 1.64%
RO 1.64%
DK 1.64%
AR 1.64%
AU 1.64%
IN 1.64%
BG 1.64%
NL 1.64%
Total 100.00%
"Docs as code" should include not only using engineering tools for docs but also aligning documentation work methodologies with engineering work methodologies (such as agile scrum).
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 2 3.33%
Disagree 3 5%
Neutral 10 16.67%
Agree 25 41.67%
Strongly agree 19 31.67%
Other 1 1.67%
Total 60 100%
Docs as code should include not only using engineering tools for docs but also aligning documentation work methodologies with engineering work methodologies (such as agile scrum). - Text Data for Other
08/23/2019 42015314 When possible
I like the agile scrum approach for docs that you recommend in this article.
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 1 1.67%
Disagree 3 5%
Neutral 5 8.33%
Agree 32 53.33%
Strongly agree 19 31.67%
Other 0 0%
Total 60 100%
I like the agile scrum approach for docs that you recommend in this article. - Text Data for Other
No Data To Display
My approach at work loosely follows what you describe in this article.
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 4 6.56%
Disagree 12 19.67%
Neutral 11 18.03%
Agree 24 39.34%
Strongly agree 8 13.11%
Other 2 3.28%
Total 61 100%
My approach at work loosely follows what you describe in this article. - Text Data for Other
08/23/2019 42015314 Past, current, and future tickets are part of my Doc Change Control spreadsheet. I share the sheet with my teams and management, but am looking forward to assigning points and building out a report. Fun!
08/21/2019 41837601 Hard to explain.
I review my docs following a similar process as you describe (review with 1. doc team, 2. product team, 3. other stakeholders such as support and field engineers, 4. legal, 5. beta partners).
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 8 13.33%
Disagree 20 33.33%
Neutral 7 11.67%
Agree 18 30%
Strongly agree 5 8.33%
Other 2 3.33%
Total 60 100%
I review my docs following a similar process as you describe (review with 1. doc team, 2. product team, 3. other stakeholders such as support and field engineers, 4. legal, 5. beta partners). - Text Data for Other
03/02/2020 58012940 Agree - I've also found it essential, depending on the doc type, to include client-focused teams like account management as they have a better feel for what clients need. Tech teams invariably end up wanting to add more detail, which isn't necessarily helpful. I do this more for release notes than things like API docs.
08/21/2019 41837601 It is just me.
I prefer to join engineering scrums rather than creating my own documentation scrums
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 3 5%
Disagree 15 25%
Neutral 9 15%
Agree 20 33.33%
Strongly agree 12 20%
Other 1 1.67%
Total 60 100%
I prefer to join engineering scrums rather than creating my own documentation scrums - Text Data for Other
09/02/2021 124846143 I'm in my first tech writer job and so my current experience is all I have to comment on - and the product team only implemented scrum one month ago, so I guess I'll have an opinion on this question in a year's time... maybe!